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THE UNIVERSITY OF MARYLAND 

SPACE PHYSICS GROUP 
Department of Physics 
College Park, Maryland 20742-41 1 1 

Tel: (301) 405-6199 F*x: ( 301 ) 314-9547 


March 7, 1996 


Dr. Arthur Poland 
Technical Officer 

Lab for Astronomy and Solar Physics 
Code 682 

NASA/Goddard Space Flight Center 
Greenbelt, Maryland 20771 


Re: NAG5-2754 


Dear Dr. Poland: 

Enclosed are three copies of the annual progress report on the above cited grant, 
“Preparation of Flight Operations and IWS Integration of the CELIAS Experiment on the 
SOHO Spacecraft”, Project Director, Dr. Fred Ipavich. 


Sincerely, 



Patricia A. Ipavich 
Research Coordinator 


cc. 


Gloria Blanchard, Code 216 - Transmittal Ltr. 

NASA Scientific & Technical Information Facility - 2 copies of report 
John Chinn, UMD Research Administration - Transmittal Ltr. 



During this reporting time period, the following activities took place: 


• Generation of several versions of the CELIAS 

( STOF/SEM/CTOF/MTOF/DPU) commissioning timeline for the first 180 
days after launch. These were written and submitted by A. Galvin after 
consultation (phone, fax, e-mail, meetings ) with the CELIAS Instrument 
Manager and Lead-Co-I’s. 

• Identification of several problems with the CELIAS portion of the Project 
Data Base (PDB). Meetings with the Flight Operations Team regarding 
PDB, critical commands, etc. 

• Attend Science Operations Working Group (SOWG) Meetings (November 

1994, February 1995, May 1995) and Flight Operations Review Meeting 
(July 1995). * 

• Participate in Flight Operation Simulations SIM 1 (November 14-18, 
1994), SIM 2 (May 1-4, 1995) and SIM3 (August 7-11, 1995). 

• Participate in the Ground System Compatibility Test Rehearsal (April 24- 
28, 1995), GSCT #2 (May 30-June 14, 1995), GSCT #3 (September 12- 
22, 1995), and GSCT #4b (October 30-November 5, 1995). 


A small portion of the documentation for the above cited activities is 
appended. 



CELIAS TIMELINE V 3.0 -1- 


CELIAS TIMELINE 
FOR THE FIRST 180 DAYS 

Submittal version 3.0 

29-NOV-1994 


(Submitted by: A.B. GALVIN) 



CELIAS TIMELINE V 3.0 -2- 


Revisions 

Change 

First submittal version. 

Changes to CTOF timeline based on discussion with H. 
Griinwaldt in 9.94. 

Day 4: CTOF turn on either in standby or manual. 

Day 4: CTOF order for IFC and SSD tests reversed. 

Day 4-12: CTOF bakeout increased from 2 days to 7 ” 

days. CTOF SSDs on for bakeout. 

All subsequent CTOF procedures delayed accordingly 
(+5 days). ' 

Day 12-14: CTOF MCP turn on changed to last 3 days. 

Day 12-180: Daily CTOF IFC commanding. 

Day 14: CTOF E/Q tests moved from day 9, and duration 
increased from 3 to 6 hours. 

Day 15: CTOF PAPS turn on moved from day 10! 









CELIAS TIMELINE V 3.0 -3- 


DAY 0 + 1H TO 

DAY 4: 

DAY 4: 

DAY 4: 

DAY 4: 

DAYS 4- 12: 
DAY 4: 

DAY 4: 

DAY 4: 

DAY 5: 

DAY 5: 

DAY 5: 

DAY 5: 

DAY 5 - 8: 

DAY 5: 

DAY 8: 

DAY 8-11: 

DAY 12: 

DAY 12: 

DAYS 12-14: 
DAY 12: 

DAY 12: 

DAY 12-180: 
DAY 12-14: 

DAY 13: 

DAY 14: 

DAY 14: 

DAY 14: 

DAY 14-19: 

DAY 14-19: 

DAY 14: 

DAY 15: 

DAY 15: 

DAY 15-28: 

DAY 16-19: 

DAY 16: 


Abbreviated TIMELINE: 


DAY 4: COMMENCE THERMAL CONTROL. 

CELIAS DPU INITIAL TURN ON. 

CTOF INITIAL TURN ON 

INITIAL CTOF CHECKOUT (SSD TEST) 

INITIAL CTOF CHECKOUT (IFC TEST) 

CTOF BAKEOUT AND OUTGASSING. 

STOF INITIAL TURN ON 

INITIAL STOF CHECKOUT (IFC TEST) 

INITIAL STOF CHECKOUT (SSD TEST) 

PREPARATION OF CTOF AND STOF FOR MTOF 

COVER RELEASE 

MTOF INITIAL TURN ON 

MTOF COVER RELEASE 

INITIAL MTOF CHECKOUT (IFC TEST). 

MTOF BAKEOUT AND OUTGASSING 
RE-TURNON OF CTOF AND STOF AFTER MTOF 
COVER RELEASE 
SET MTOF/MAIN POST-BAKEOUT 
RECONFIGURATION 

MTOF MAIN & PM MCP INITIAL TURN ON 

PREPARATION OF CTOF AND MTOF FOR STOF 

SHUTTER RELEASE 

STOF SHUTTER RELEASE 

STOF BAKEOUT AND OUTGASSING 

CTOF and MTOF RECONFIGURATION AFTER 

STOF SHUTTER RELEASE 

CTOF POST-BAKEOUT RECONFIGURATION 

CTOF DAILY IFC TEST 

CTOF MCP INITIAL TURN ON 

MTOF PROTON MONITOR E/Q INITIAL TURN ON 

STOF POST-BAKEOUT RECONFIGURATION 

SEM INITIAL TURN ON 

MTOF MAIN WAVE E/Q INITIAL TURN ON 

STOF MCP1 INITIAL TURN ON 

STOF MCP2 INITIAL TURN ON 

CTOF E/Q INITIAL TURN ON 

MTOF WAVE/PM FLIGHT CONFIGURATION 
HSTOF E/Q INITIAL TURN ON 
CTOF PAPS INITIAL TURN ON 

MTOF MAIN HYPERBOLA INITIAL TURN ON 
STOF E/Q INITIAL TURN ON 



CELIAS TIMELINE V 3.0 -4- 


DAY 19: 
DAY 19: 
DAY 19: 

DAY 20-22: 

DAY 23: 
DAY 23: 
DAY 23: 

DAY 24 - 30: 


DAY 30: 

DAY 60 & 76: 

DAY 114: 
DAY 1 14: 
DAY 114: 

DAY 115-119: 

DAY 120: 
DAY 120: 
DAY 120: 

DAY 121-125: 

DAY > 120: 


CTOF PREPARATION FOR MCC2 
MTOF PREPARATION FOR MCC2 
STOF & SEM PREPARATION FOR MCC2 

S/C MANUEVERS 

CTOF RECONFIGURATION AFTER MCC2 
MTOF RECONFIGURATION AFTER MCC2 
STOF/SEM RECONFIGURATION AFTER MCC2 

MTOF HYPERBOLA HV TURN ON CONTINUES 
AFTER MCC2 

MTOF MAIN Vf INITIAL TURN ON 

CELIAS CONFIGURATION FOR S/C MANUEVERS 

CTOF PREPARATION FOR HOI 
MTOF PREPARATION FOR HOI 
STOF & SEM PREPARATION FOR HOI 

S/C MANUEVERS for HOI 

CTOF RECONFIGURATION AFTER HOI 
MTOF RECONFIGURATION AFTER HOI 
STOF & SEM RECONFIGURATION AFTER HOI 

MTOF HYPERBOLA HV TURN ON CONTINUES 

S/C IN HOP: THRUSTER OPERATIONS 


Prom: UMDSP: j GALVIN "Toni Galvin (Univ. Md) " 10-MAY-1995 17:13-17 71 

To : @SOWG 

CC : GALVIN 

Subj : more soho early ops requests 

Dear Celias SOWG distribution: 

The following refers to the post -launch early operations timeline: 

The timeline for the intial operations on SOHO are in" a state 
of flux, as Matra Marconi has finally given its input and they do not 
want to turn on instruments as originally planned (i.e., on day 4). I 
believe that in general the experiment commissioning will not start until 
on or after day 14 . 

However, CELIAS (plus one or two other experiments) is still slated 
for an early low voltage turn on for the purpose of (1) bakeout, and 
(2) turning on the Solid State Detector bias in CTOF and STOF in order to 
make sure they are functioning correctly. I spoke to Piet Martens this 
morning, and we will keep this in the timeline, but officially Piet will 
tell the project that the SSD test is to assist in the bakeout. 

If Piet has problems selling the SSD bias to the project, I have 
spoken to Fredi Buergi this morning, and we feel that it is not important 
enough to make an issue out of it. I have told Piet that the SSD bias is 
the only bias we would turn-on during this two week period -- no High 
Voltage commands would be sent. 

As far as breaking up the procedures into smaller chucks of time - - I 
think this has to be done by each sensor team, as you have to decide if 
the sensor can be left in a particular state overnight until the next 
commanding session is available. The problem has to do with the fact that 
we will not have 24 hour command capability, so smaller time chucks may be 
required (some commanding times are only 1.3 hours long, and that also includes 
the set up time for the FOT) . 

I had already tried to incorporate some of the relevant information in 
the original timeline that I gave Piet (and you) last fall (such as estimated 
duration, preferred time - relative to other operations, etc.) 

For your recollection, this came under the action item from the Feb 1995 
SOWG: 


***************** 

13.19 On Pis, due on March 15: 

Switch- on scenario. Each instrument team decribe the blocks of their 
activities to be scheduled before MCC2 . For each block indicate: 

1. Preferred time 

2. Earliest time 

3 . Latest time 

4. Estimated duration (no contingency, the FOT will put that in) 

5. Where it can be broken in parts, if at all 

6. Relevant procedures to be run by FOT 

7. Prerequisites 

8 . Importance 
Input to Piet Martens . 

****************** 

Piet requires the input by the end of the month --if you can mark up the 
timeline that you have and fax or express mail your comments within the next 
10 days, I can incorporate these into the timeline document. 



Thanks , Toni 


From: MX% "pmartens@esa.nascom.nasa.gov" 10 -MAY- 1995 09:24:24.93 

To: MX%" galvin@umdsp.umd.edu" 

Subj : Commissioning 

Hi Toni, 

Can you reply to this a.s.a.p.!! That is today, before 12:30 
(I am flying to ESTEC later today and need some sort of reply) . 

I also left a message on your answering machine this morning. 

If you can't reach me this morning, please send an e-mail to 
me with copy to Domingo, so I can read it tomorrow morning at 
ESTEC. 

First thing I need to know is about early switch- on for 
CELIAS. I have in my notes that it is need to put a bias voltage 
on the high voltage circuits. Is that correct? If so, which part 
of the CELIAS timeline needs to be carried out for that. This 
information I need today. 

By the end of the month I will have to submit drafts of the 
experiment timelines arranged in logical blocks, (a block is a 
series of activities that belong logically together, and that have 
to be performed uninterrupted) . Looking at the CELIAS timeline I 
find that very difficult. (This request was also formally made 
for the early phase of the commissioning as SOWG13-19) . Can you 
make a draft? 

Thanks for your help, 


Piet 



From: MX% "pmartens@esa.nascom.nasa.gov" 19-MAY-1995 15:25:17.20 

To : MX% "galvin@umdsp . umd . edu" , MX% "buergi@mpe-garching . mpg . de " , MX% "wurz@phim. 

Subj : CELIAS Commisioning 

Return- Path: <pmartens@esa . nascom. nasa . gov> 

Received: from gsfc.nasa.gov by UMDSP.UMD.EDU (MX V4.0-1 VAX) with SMTP; Fri, 

19 May 1995 15:25:14 EDT 

Received: from esa.nascom.nasa.gov by gsfc.nasa.gov (5 . 65/Ultrix3 . 0-C) id 
AA20524 ; Fri, 19 May 95 15:25:42 -0400 

Received: from lion by esa (5 . 0/SMI-SVR4) id AA23598; Fri, 19 May 1995 15-25-34 
-0400 

From: pmartens@esa.nascom.nasa.gov (Petrus C. Martens) 

Received: by lion (5.0) id AA11385; Fri, 19 May 1995 15:25:39 -0400 
Date: Fri, 19 May 1995 15:25:39 -0400 
Message- ID: <9505191925 . AA11385@lion> 

To: galvin@umdsp.umd.edu, buergi@mpe-garching.mpg.de, wurz@phim.unibe . ch, 
dhovestadt@solar . Stanford . edu 
Subject: CELIAS Commisioning 
X -Sun- Charset : US-ASCII 
Content -Length: 7949 

Dear Tony, 

Last week I had a meeting with the SOHO ESA Project people on 
commissioning. I reported the CELIAS request for early (i.e. before 
day 14) turn-on "to protect your high-voltage circuits and for enhanced 
outgassing" . - - this was my summary of the phone conversation we have 
had two weeks ago. The ESA Project said the reason for the request was not 
clear, and they asked me to contact you to clarify this. Can you please 
send me a short write-up (1 page at most) to justify early switch-on, 
that I then can show to the ESA Project by the next meeting (which is 
on June 5)? Please submit before the end of the month. 

Please note that without this the ESA Project may go ahead and 
not schedule an early CELIAS switch- on before day 14. 

I also took the liberty to try to subdivide the CELIAS timeline 
you have submitted last August into "blocks", i.e. logical units that 
are more or less separate in purpose and time. The ESA Project intends to 
produce an integrated SVM plus experiments timeline on the basis of these 
blocks, which will be part of the final "commissioning plan" . 

Please review the appended CELIAS blocks and comment and/or correct 
(edit) --as you can see I got somewhat lost near the end. The main problem 
I have is that the Project wants to use those blocks to carry out important 
commissioning events in series, while in your timeline several events run 
in parallel. Please try to justify it when you run things in parallel 
(to save time, no mutual interaction, this has been done before, etc.). 

For this too I will need your response by the ned of the month. 

Thanks for your help, 

Piet Martens 

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 
CELIAS COMMISSIONING PLAN ORGANIZED IN BLOCKS 



From: UMDSP: : GALVIN "Toni Galvin (Univ. Md) " 31-MAY- 1995 22:45:08.99 

To: MX% "pmartens@esa.nascom.nasa.gov" 

CC: @SOWG, GALVIN 

Subj : RE: CELIAS Commisioning 

Dear Piet, 

I have - now received input from my CELIAS colleagues regarding 
early operations : — 

STOF and CTOF will delay any operations until after the first 
two weeks devoted to s/c operations, but would then like to start 
operations on the first day that is open for the instrument commanding 
(day 14 or 15) . 

MTOF would like to open it's cover on day 10 (with a window of 
acceptability of day 8 to 12) . In order to monitor the opening of the 
cover, we would need to turn on the DPU and the MTOF sensor. Our 
preference (this is not a requirement) would be to have the DPU and MTOF 
sensor remain on after the cover is open. We would like the heaters to 
remain on with the sensor on, but that is of secondary importance. 

The next set of commands would being at or after day 14, when STOF 
would open its shutter (MTOF would be turned off /on during the STOF 
shutter opening, or if MTOF is off it as well as CTOF will be turned 
on after the shutter opening) . 

The motivation for the early cover opening for MTOF is as follows: 

(1) Improve confidence level on a successful door opening because long 
delays increase the range of thermal gradients experienced by the 
door mechanism, and may also affect lubrication levels. 

(2) Improve the thermal environment of the MTOF sensor to decrease the 
probability of condensation of volatiles on the thermal blanket 
(said condensation decreases the lifetime and effectiveness of 
the thermal blanket) . This is accomplished by opening the 
cover, because that increases dramatically the thermal input to 
the sensor. This would be further aided by keeping the sensor and 
heaters on after the cover opening. 

(3) Increases the rate of outgassing. 


We would require both Sci and Hk data in order to confirm the door 
opening . 


As regards the blocking of commands, this depends on what day we 
start each sensor activation. 


Regards, Toni Galvin 



From: MX% "pmartens@esa.nascom.nasa.gov" 27-JUN-1995 13:09:23.80 

To : MX% " galvin@umdsp . umd . edu " 

CC: MX% "svaghi@estcsl.estec.esa.nl" 

Subj : CELIAS commissioning plans 

Return- Path: <pmartens@esa . nascom. nasa . gov> 

Received: from gsfc.nasa.gov by UMDSP.UMD.EDU (MX V4.0-1 VAX) with SMTP; Tue, 
27 Jun 1995 13:09:19 EDT 

Received: from esa.nascom.nasa.gov by gsfc.nasa.gov (5 . 65/Ultrix3 . 0-C) id 
AA10289 ; Tue, 27 Jun 95 13:09:55 -0400 

Received: from lion by esa (5 .x/SMI-SVR4) id AA25729; Tue, 27 jun 1995 13:09:54 
-0400 

From: pmartens@esa.nascom.nasa.gov (Petrus C. Martens) 

Received: by lion (5.x) id AA00450; Tue, 27 Jun 1995 13:09:52 -0400 
Date: Tue, 27 Jun 1995 13:09:52 -0400 
Message -ID: <9506271709 . AA00450@lion> 

To : galvin@umdsp . umd . edu 
Subject: CELIAS commissioning plans 
CC: svaghi@estcsl.estec.esa.nl 
X -Sun- Charset : US-ASCII 

Dear Tony, 

In preparing a SOHO-wide commissioning plan, I have reached the 
stage now where I need the commissioning plans for CELIAS updated. 

Let me first explain what I have from you, and then what is needed. 

1. In August last year I received from you a complete and detailed 
CELIAS timeline 

2 . Late May I received from you an update and justification for 
early CELIAS switch- on (i.e. MT0F switch- on at day 10) . 

ESA Project has agreed to this plan. 

3. I have used your timeline to try to organize your commissioning 
plan in so-called blocks, i.e. functional units, that will be 
scheduled and carried out as blocks. A copy of my attempt is 
appended to this message . 

However, this block schedule is no longer consistent with the CELIAS 
plsns after your changes in early switch- on schedule in reponse to the 
ESA Project "rules". Therefore I am asking you to review the appended 
block schedule, correct and update it it where necessary, and in particular 
rearrange the order and timing of the blocks to coincide with the present 
CELIAS switch- on plans. 

Please reply to me a.s.a.p. (or call 286-9028) to give me an idea 
of when I can expect input. My preference is input before the end of 
the week, so your submission can be part of the first issue of the 
official SOHO Commissioning Plan, to be reviewed at the ESA/NASA Flight 
Operations Review on July 11 and 12. But if that can't be done it will 
have to be part of a later issue. However, I still need your input as 
well to load into the SOHO mission planning tool — we are in the process 
now of loading the information of the other experiments. 

Thanks for your help, 

Piet 

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $ $ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 

CELIAS COMMISSIONING PLAN ORGANIZED IN BLOCKS 



UMDSP: : GALVIN "Toni Galvin (Univ. Md) " 31-JUL-1995 19:29:01.80 

MX% "pmartens@esa . nascom. nasa . gov" 

IPAVICH , BED INI , @MPE , GALVIN 
initial comments on SOHO timeline 

Dear Piet, 

I am still waiting for input from CTOF, STOF, DPU, and SEM 
representatives regarding the SOHO timeline dated 24 July 1995. 

However, I have some items right away to mention - including 
some information on the MTOF response. 

Overall, I think you did an excellent job. 

(1) day 21 & 02:00:05 CELIAS continue normal obs.????? We are 
in standby here, but I could use the time for something else 
(see point 4) 

(2) under day 24, you wrote 25 & 16:00 instead of 24 

(3) for day 24 0900-1600 = 7 hours, but you say 8? 

day 25 1000-1600 = 6 hours, but you say 8? 

day 27 0900-1700 = 8 hours, ok 

day 28 0900-1700 = 8 hours, ok 

day 29 0900-1700 = 8 hours, ok 

(4) Specifically regarding the MTOF high voltage turn on: It is 

ok to start after the MCC2 manuever, instead of the my original 
timeline (which started on day 17) . BUT ... 

MTOF has eight high voltage power supplies. We had planned to 
turn them on in a staggered manner as outlined below, which 
takes 9 days (you have 5 days allocated to the combined CELIAS 
high voltage turn on) . These need not be full 8 hour days - the 
point is that we want to have the MTOF high voltages "sit" at the 
lower levels on the order of a day or so before going to the 
next voltage level. The first turn on for any high voltage 
in space is usually very conservative, and time is allowed 
for the voltages to "burn off" any residuals left from outgassing. 
(This is not as essential for subsequent turn ons later in the 
mission, since the burn off has already been accomplished.) 

We also wanted some high voltages turned on before others, since it 
would tell us more information. For example, having the 
MicroChannel Plates (MCPs) operational before turning on the 
deflection system allows us to see if the cover has opened, 
the carbon foil survived, and UV is suppressed. It also allows 
us to devote our attention to one supply at a time. 

Anyway , what we would like, and I am speaking at this time 
specifically for MTOF until I hear from the other sensors, 
is to take the time already mentioned for day 21 (point l above) 
and use it to start the MTOF MCP turn on. If an hour were 
available, that would be even better, but we would take anything. 

If we could again get at least a half hour, but better an hour, 
on any or all of days 22, 23, 26, then in combination with the 
time you have already allotted, we think we can get MTOF 
to full operational voltage by the end of day 29, as you have 
shown . 


From: 
To: 
CC: 
Subj : 



From: UMDSP: : GALVIN "Toni Galvin (Univ. Md) " 17-AUG-1995 17:49:37.02 

To: @LEAD_COI, @MPE 

CC : GALVIN 

Subj : celias timeline 4.1 - with some typos corrected! 

To: Lead Co- Is: 

This is a "cleaned up" version of what I sent you yesterday. I have 
found instances of miscounting in the "sub-block" numbers, and I have 
also corrected some misspellings. Some of that was due to working via 
modem at 1 am - in any case feel free to throw out the earlier version. 


Please feel free to comment. I have spoken to most of you, but 
sometimes writing it down all together shows that some further 
revisions may be necessary. I am sorry for the rush, but this 
was due on 15 August, so I must have any further changes immediately! 

Toni 

TO: ALL LEAD CO- Is: 

Please place special attention on the HV turn on. I am 
concerned about the fact that CTOF, MTOF, STOF, SEM all 
h^ve HV' s going on at one time. Any good suggestions 
are appreciated. 


TO: MARTIN HILCHENBACH (STOF) 

I have tried to incorporate both your and Dieter's comments, but 
sometimes these may not correlate well with the time constraints. 

Day 14: Since you now do not want the SSDs on during bakeout, I 

do not see how to get the background SSD run with shutter- open 
on the same day as shutter release and before bakeout starts, and 
having a requirement that the background run be at least 2 hours 
but a safety requirement that it be less than 4 hrs (i.e., a 4 hour 
max limit on the test generator). I have put it in, but 
I will be surprised if you get it all as requested since other 
experiments have commands that day. If you can suggest a more "friendly 
timeline here it would be good. 

Is there still any need for the "initial configuration" on day 16 
( a fter bakeout ends) and (I've added request) day 21 after MCC2, as 
we do not get to do anything with STOF until day 24 after MCC2 anyway? 

TO: FRED IPAVICH (MTOF) 

Our original request for MTOF HV commanding was condensed by 
Martens from 11 days (40 hours) to 5 days (40 hours in parallel 
with CTOF and STOF) . I am trying to get 2-4 hours on days 22, 23, 

26, and 30, 31, 32, 33 but it definitely means a slower turnon (day 33 
instead of our original intent of day 30) . 

Is there still any need for the "MTOF initial configuration" on day 16 
(after bakeout ends) , as we do not get to do anything until after MCC2 a 


********* CELIAS TIMELINE V4 . 1 (16-AUG-95) 


************** 



This timeline tries to conform as well as possible to the integrated 
timeline Draft 0.0. But DO . 0 did not give us the HV time requested. 

It must be remembered that commands cannot be sent "simultaneously" by 
CTOF, MTOF, STOF, and SEM. Only one CELIAS IWS can command at a given time, 
and if FOT TSTOL procedures are used, no commands can be sent from the 
IWS until_ the procedure ends . (Most HV sequences were expected to be 

TSTOL procedures, although none exist yet.) However, we can run in 
parallel in the sense by using the command- times allocated to other CELIAS 
sensors as "wait-and monitor" periods for a given sensor. 

MTOF has not requested any revisions. 

CTOF has revised its HV procedures to be spread over 6 days 
(HGruenwaldt , fax 15Aug95) 

STOF/SEM has revised its HV request to be two days, 4hours/day , for a 
total of 8 hours (can run concurrent with CTOF and MTOF if feasible) , 
but without specific details as to power supplies - so I have 
simply assigned time units (DHovestadt, meeting GSFC HAug95) 

I try not to send any HV commands for the last hour of command 
availability, so that we can monitor the last HV commands and 
change configuration to a lower level if needed. This is not 
meant to be an "overflow" command period for running late! 

Rather, the intent is that we have time to monitor a high voltage 
change for at least an hour before command capability is lost. I 
indicate this as "Evaluation Time". 

Obviously, if a sensor has an emergency, it will need to access the 
command time that may nominally assigned to another CELIAS sensor. 

I think we have to deal with it as (or if) it occurs. 

ALSO - The SOC is supposed to added contingency time to 
our request, we have been asked not to do so. 

I have mixed up the time allocation among the sensors in order to 
make one sensor's "wait and monitor" period another sensor's command 
period. That is why there are certain time orders suggested. These 
are internal to CELIAS use for planning purposes, and can be changed. 

It is an attempt to see how much time is really needed, with commanding 
of different CELIAS units running in parallel. 

In looking over the original request in CELIAS timeline version 4.0, 
we had requested the following time allocation for high voltage turn on: 


CELIAS UNIT 

V4.0 (*) 

V4.1 


CTOF 

2 6 hours 

15.5 

hours 

MTOF 

34 hours 

20.25 

hours 

STOF/SEM 16.5 

- 28.5 hours 

8.5 

hours 

EVALUATION TIME 

0 

8 

hours 


(before loss of 
command capability) 

TOTAL 76.5 - 88.5 hours (*) 52.25 hours 

(*) In Version 4.0, many of these units were expected to run 

HV commands in parallel, so actual command time would have 
been less, but it was unclear how much less. In version 
4.1, I have tried to take the "parallel" commanding into 



account . 


; New attempt for HV timeline as follows: 

> Day 22. NO CELIAS TIME ASSIGNED. 

; MTOF request for 2.5 hours - this allows MCPs to only get to 

' level 110 (four MCPs, requiring limits, levels, enables for 3 

»’ separate levels) 

Day 23. NO CELIAS TIME ASSIGNED. 

MTOF request for 2 hours - MCPs to new warm up level 125, but 
still not operational. (Before, this level was reached on 
one day, but for that we need 4 hours of command time.) 

Day 24. Because of changes in CTOF and STOF schedules, there will no 

longer be 8 hours on day 24 for HV commanding, even if MTOF can 
get some commands in near the start. The following assumes 
MTOF got the required time (or more) on days 22 and 23. 

summary: STOF/SEM gets 2:25 hrs command time 

CTOF gets 2:30 

MTOF gets 2 : 15 

Note: obviously, limits as well as levels have to be set and 

for a given high voltage, so multiple commands 
are involved. 

09:00 - 09:15 STOF starts IFC, then turns over commands to MTOF 

09 ; 15 - 10:00 MTOF four MCPs increase by one level to 130, then 

turns over commands to CTOF 

10:00 - 10:30 CTOF initial configuration, then over to STOF 

10:30 - 10:40 STOF stops IFC, then over to MTOF 

10:40 - 11:25 MTOF four MCPs one level to 135 

11:25 - 12:25 CTOF MCPs levels 0 and 1, HVPS to step 0 (4kV) 

12:25 - 13:25 STOF one hour (1 of 8 requested hours) 

13:25 - 14:10 MTOF MCPs one level to 140 (NEUTRAL, PM MCPs opera 

14:10 - 15:10 CTOF MCPs level 2 and 3, HVPS to step 1 (lOkV) 

15:10 - 16:10 STOF one hour (2 of 8) 

16:10 - 17:00 EVALUATION command period (end of Commanding at 1 


Day 25. HV turn on continues 

summary: STOF/SEM gets 3:30 hrs command time 

CTOF gets 1:00 

MTOF gets 2:30 

09:00 - 09:30 MTOF START and ION MCPs to level 145 (START MCP o 
09:30 - 10:30 CTOF MCPs to level 4, HVPS to step 2 (15kV) 

10:30 - 11:30 STOF 1 hour (3 of 8) 

11:30 - 12:00 MTOF ION MCP to level 150 
12:00 - 13:00 STOF 1 hour (4 of 8) 

13:00 - 13:30 MTOF ION MCP to level 155 (ION MCP operational) 
13:30 - 14:30 MTOF PM E/Q initial turn on (3kV) 

14:30 - 16:00 STOF 1.5 hour (5.5 of 8) 

16:00 - 17:00 EVALUATION command period 


DAY 26. NO CELIAS TIME ASSIGNED. 

No CELIAS time in D0.0, but here request 30 minutes. Trying to 



get PM operational by day 27 
00:00 - 00:30 MTOF PM E/Q to 4 kV. 


DAY 27 


DAY 28. 


DAY 29. 


DAY 30. 


DAY 31. 


. CELIAS 8 hours of HV commanding. 



summary 

: 

STOF/SEM 

gets 

2:00 




CTOF 

gets 

1:30 




MTOF 

gets 

3:30 

09:00 - 

10:00 

MTOF 

HPS to 0, 50 



10:00 - 

10:30 

CTOF 

MCP to level 

5 


10:30 - 

11:00 

CTOF 

HVPS to step 

3 (19 

kV, 

11:00 - 

11:30 

MTOF 

HPS to level 

80 


11:30 - 

13:30 

STOF 

2 hour (7.5 < 

of 8) 


13:30 - 

15:30 

MTOF 

WAVE to 4kV 

( Fred : 

I r< 

15:30 - 

16:00 

CTOF 

MCP close to 

level 

4 

16:00 - 

17:00 

EVALUATION command period 


reduced this from 3 to 


CELIAS 8 hours of HV commanding. 


summary: 


STOF/SEM gets 1 hrs command time 
CTOF gets 4:30 

MTOF gets 1:30 


09:00 

09:30 

10:00 

10:30 

11:00 

12:00 

12:30 

15:30 

16:00 


09:30 MTOF HPS to level 90 

10:00 CTOF MCP to level 6 

10:30 CTOF HVPS to step 4 (23 kV, CTOF HVPS operationa 
11:00 MTOF HPS to level 100 

12:00 STOP 1 hour (8.5 of 8, STOF/SEM operational) 
12:30 MTOF WAVE to 6 kV 

15:30 CTOF WPS turn on (3 hours reserved time needed) 

16:00 CTOF MCP close to level 5 (CTOF MCP operational) 

17:00 EVALUATION command period 


CELIAS 8 hours of HV commanding. 


summary: 


CTOF gets 3:00 hrs of command time 

MTOF gets 1:30 


09:00 

- 09:30 

09:30 

- 10:30 

10:30 

- 11:00 

11:00 

- 13:00 

13:00 

- 13:30 

13:30 

- 14:30 

14:30 

- 17:00 


MTOF HPS to level 110 

CTOF WPS turn on (1 of 3 hours reserved time) 
MTOF HPS to level 120 

CTOF WPS turn on (last 2 of 3 hours reserved ti 
MTOF WAVE to 8 kV 
EVALUATION command period 

Time can be released to other experiments, or 
does MTOF feel lucky and want to go higher?? 


NO TIME ASSIGNED TO CELIAS. 

REQUEST for 4 hours of HV commanding 


09:00 - 09:30 MTOF HPS to level 130 

09:30 - 12:30 CTOF WPS turn on (3 hours reserved time, CTOF o 

12:30 - 13:00 EVALUATION command period (half hour only). 

NO TIME ASSIGNED TO CELIAS. 

REQUEST for 2 hours of HV commanding 



09:00 - 09:30 MTOF WAVE to 10 kV. 

10:30 - 11:00 MTOF HPS to 140 

11:00 - 12:00 EVALUATION command time. 

DAY 32. NO TIME ASSIGNED TO CELIAS. 

REQUEST for 2 . 5 hours of HV commanding 

09:00 - 09:30 MTOF WAVE to full operational voltage. 

10:30 - 11:00 MTOF HPS to 150 

12:00 - 12:30 MTOF HPS to 160 

12:30 - 13:30 EVALUATION command time. 

DAY 33. NO TIME ASSIGNED TO CELIAS. 

REQUEST for 2 hours of HV commanding 


09:00 - 09:30 
10:30 - 11:00 
12:00 - 13:00 


MTOF Vf to +-1 kV (minimum operational voltage) 
MTOF HPS to 170 (minimum operational voltage) 
EVALUATION command time. 


, ********* TIMELINE FORMAT **************** 

; Time-line has the format: 

: Time # Experiment Name or SVM # Sheet Identifyer: Action # Duration, Notes 

; Time has the format: d & hh:mm:ss, or d & hh:mm 

; Blank lines and comment lines -- preceeded by -- are ignored 

; The purpose of this format is to make the file machine readable for ease of sc 
; and transfer to planning tools 

; ********* BLOCK GROUPING OF PROCEDURES **************** 

"BLOCKS" are used to differentiate different types of activities. The 
following designation has been requested by the SOC: 

1: (early) switch on 

2: functional commissioning 

3: calibrations 

4: science tests 

and I've added number block 5 

5 : s/c manuevers 

Different activities within a block that can (or must) be scheduled at 
different days are registered as sub-blocks, which would be the largest 
unit that must be uninterrupted during the same s/c contact. A 
sub -block can consist of a whole sequence of experiment 
commands or operations. 

I do not believe the above designation works too well with CELIAS as we 
have 5 separate units turning on at different times (DPU, CTOF, STOP MTOF 
SEM) , but I use it to comply with the SOC's request. , , 


********* REVISIONS **************** 

The following is derived from Draft 0.0 by P. Martens (dated 24 July 1995) 
This draft version includes an attempt at incorporating the CELIAS requested 
timeline (CELIAS timeline version 4.0, dated 21 July 1995) into the s/c and 
other experiment requests . 



From: UMDSP: : GALVIN "Toni Galvin (Univ. Md) " 24-AUG-1995 20:40:16.71 

To : MX% "pmartens@esa . nascom. nasa . gov" 

CC : GALVIN 

Subj : extended version of CELIAS HV plans - for your info 

Dear Piet, 

In order to help you understand the requests I made regarding the HV times 
CELIAS, this is the more detailed timeline of how the high voltage 
command sequences plan to be sent, assuming you can find us the time on the 
appropriate days . 


best regards , toni galvin 


; ********* CELIAS HIGH VOLTAGE TIMELINE V4.2 (24-AUG-95) ************** 

; It must be remembered that commands cannot be sent "simultaneously" by 
; CTOF, MTOF, STOF, and SEM. Only one CELIAS IWS can command at a given time, 

; and if FOT TSTOL procedures are used, no commands can be sent from the 
; IWS until the procedure ends. (Most HV sequences were expected to be 
; TSTOL procedures, although none exist yet.) However, we can run in 
; parallel in the sense of using the command times allocated to other CELIAS 
; sensors as "wait and monitor" periods for another CELIAS sensor. 

; After a review of SOHO timeline DO.O by the CELIAS PI and Lead Co- Is, 

; the following changes to the MTOF, CTOF, STOF, SEM high voltage sequences 
; were requested: 

; MTOF changed some details, but not total time request (Flpavich, UMd 18Aug95) . 

; CTOF has revised its HV procedures to be spread over 6 days 
; (HGruenwaldt , fax 15Aug95) 

; STOF/SEM has revised its HV request to be two days, 4hours/day , for a 
; total of 8 hours (can run concurrent with CTOF and MTOF if feasible), 

; but without specific details as to power supplies - so I have 
; simply assigned time units (DHovestadt, meeting GSFC HAug95) 

; I try not to send any HV commands for the last hour of command 
; availability, so that we can monitor the last HV commands and 
; change configuration to a lower level if needed. This is not 
; meant to be an "overflow" command period for running late! 

; Rather , the intent is that we have time to monitor a high voltage 
; change for at least an hour before command capability is lost. I 
; indicate this as "Evaluation Time". 

; I have mixed up the time allocation among the sensors in order to 
; make one sensor's "wait and monitor" period another sensor's command 
; period. That is why there are certain time orders suggested. These 
; are internal to CELIAS use for planning purposes, and can be changed. 

; It is an attempt to see how much time is really needed, with commanding 

; of different CELIAS units running in parallel. 

; In looking over the original request in CELIAS timeline version 4.0, 

; we had requested the following time allocation for high voltage turn on: 


CELIAS UNIT 


V4.0 (*) 


V4.2 



CTOF 

MTOF 

STOF/SEM 16.5 

EVALUATION TIME 
(before loss of 
command capability) 


2 6 hours 
34 hours 
28.5 hours 
0 


TOTAL 


76.5 - 88.5 hours (*) 


15.75 hours 
21.50 hours 
8 . 5 hours 
8 . 3 hours 


54.05 hours 


(*) In Version 4.0, many of the CELIAS units were expected to r 
HV commands in parallel, so actual command times were 
expected to be less than the total given here, 
but it was unclear how much less. In version 4.2, 

I have tried to take "parallel" commanding specifically int 
account in order to get a more accurate time estimate. 


New attempt for HV timeline as follows: 

Day 22. NO CELIAS TIME ASSIGNED. 

MTOF request for 2.5 hours - this allows MTOF MCPs to get to 
level 110 (four MCPs, requiring limits, levels, enables for 3 
separate levels) 


summary: STOF/SEM 0 hrs command time 

CTOF 0 

MTOF 2:30 

Day 23. NO CELIAS TIME ASSIGNED. 

MTOF request for 2 hours - START/NEUTRAL/ ION/ PM (SNIP) MCPs to 
increased warm up levels SNIP = 120, 130, 125, 125. 

Still not operational. 

summary: STOF/SEM 0 hrs command time 

CTOF 0 

MTOF 2 : 00 

Day 24. Because of changes in CTOF and STOF schedules, there will no 

longer be 8 hours on day 24 for HV commanding. The following a 
MTOF got the required time (or more) on days 22 and 23. 


summary: STOF/SEM 2:25 hrs command time 

CTOF 2:45 

MTOF 2:00 

Note: obviously, limits as well as levels have to be set and 

verified for a given high voltage, so multiple commands 
are involved . 


09:00 

09:15 


10:00 

10:30 

10:40 

11:25 

12:25 

13:25 


09:15 STOF starts IFC, then turns over commands to MTOF 
10:00 MTOF PM threshold = 0. MTOF four MCPs increase 
by one level to SNIP = 125, 135,130,130, then 
turns over commands to CTOF 
10:30 CTOF initial configuration, then over to STOF 
10:40 STOF stops IFC, then over to MTOF 

11:25 MTOF four MCPs one level to SNIP =130,140,135,135 

N operational at 140 

12:25 CTOF MCPs levels 0 and 1, HVPS to step 0 (4kV) 
13:25 STOF one hour (1 of 8 requested hours) 

13:55 MTOF MCPs one level to SIP = 135,140,140 

P operational 



13:55 - 15:10 CTOF MCPs level 2 and 3, HVPS to step 1 (lOkV) 
15:10 - 16:10 STOF one hour (2 of 8) 

16:10 - 17:00 EVALUATION command period (end of Commanding at 1 

Day 25. HV turn on continues 

summary: STOF/SEM 3:30 hrs command time 

CTOF 1:00 

MTOF 2:30 

09:00 - 09:30 MTOF START and ION MCPs to levels SI=140,145 

09:30 - 10:30 CTOF MCPs to level 4, HVPS to step 2 (15kV) 

10:30 - 11:30 STOF 1 hour (3 of 8) 

11:30 - 12:00 MTOF START and ION MCPs to levels SI=145,150 

S, I operational 

12:00 - 13:00 STOF 1 hour (4 of 8) 

13:00 - 13:30 MTOF PM E/Q initial turnon to 2kV, not stepping 

13:30 - 14:30 MTOF PM E/Q turn on to 3kV, not stepping 

14:30 - 16:00 STOF 1.5 hour (5.5 of 8) 

16:00 - 17:00 EVALUATION command period 


DAY 26. NO CELIAS TIME ASSIGNED. 

No CELIAS time in DO . 0 , but here request 30 minutes. Trying to 
get PM operational by day 27 for use by CTOF for its turn on. 

summary: STOF/SEM 0 hrs command time 

CTOF 0 

MTOF 0:30 

00:00 - 00:30 MTOF PM E/Q to 4 kV, not Stepping 


DAY 27. CELIAS 8 hours of HV commanding. 

summary: STOF/SEM 2:00 hrs command time 

CTOF 1:30 

MTOF 3:30 

09:00 - 10:00 MTOF HPS to 0, 50 

10:00 - 10:30 CTOF MCP to level 5 

10:30 - 11:00 CTOF HVPS to step 3 (19 kV, minimum operational) 

11:00 - 11:30 MTOF HPS to level 80 

11:30 - 13:30 STOF 2 hour (7.5 of 8) 

13:30 - 15:30 MTOF WAVE to 6kV 

15:30 - 16:00 CTOF MCP close to level 4 

16:00 - 17:00 EVALUATION command period 

DAY 28. CELIAS 8 hours of HV commanding. 

summary: STOF/SEM 1 hrs command time 

CTOF 4:30 

MTOF 1:30 

09:00 - 09:30 MTOF HPS to level 90 

09:30 - 10:00 CTOF MCP to level 6 

10:00 - 10:30 CTOF HVPS to step 4 (23 kV, CTOF HVPS operationa 
10:30 - 11:00 MTOF HPS to level 100 

11:00 - 12:00 STOF 1 hour (8.5 of 8, STOF/SEM operational) 



12:00 - 12:30 MTOF WAVE to 8 kV 

12:30 - 15:30 CTOF WPS turn on (3 hours reserved time needed) 

15:30 - 16:00 CTOF MCP close to level 5 (CTOF MCP operational) 

16:00 - 17:00 EVALUATION command period 

DAY 29. CELIAS 7 hours of HV commanding. 

summary: STOF/SEM 0:00 hrs of command time 

CTOF— 3:00 

MTOF 3:00 


09:00 - 09:30 MTOF HPS to level 110 

09:30 - 10:30 CTOF WPS turn on (1 of 3 hours reserved time) 

10:30 - 11:00 MTOF HPS to level 120 

11:00 - 13:00 CTOF WPS turn on (last 2 of 3 hours reserved ti 

13:00 - 13:30 MTOF WAVE to 10 kV 

13:30 - 15:00 MTOF engage nominal mode - first stepping for 

PMEQ and WAVE 

15:00 - 16:00 EVALUATION command period 

DAY 30. NO TIME ASSIGNED TO CELIAS. 

REQUEST for 4 hours of HV commanding 

summary: STOF/SEM 0:00 hrs of command time 

CTOF 3:00 hrs 

MTOF 0:30 


09:00 - 09:30 MTOF HPS to level 130 (minimal level for ops) 

09:30 - 12:30 CTOF WPS turn on (3 hours reserved time, CTOF o 

12:30 - 13:00 EVALUATION command period (half hour only). 

DAY 31. NO TIME ASSIGNED TO CELIAS. 

REQUEST for 2 hours of HV commanding 

summary: STOF/SEM 0:00 hrs of command time 

CTOF 0:00 

MTOF 1:00 

09:00 - 09:30 MTOF WAVE to 11 kV. 

10:30 - 11:00 MTOF HPS to 140 

11:00 - 12:00 EVALUATION command time. 

DAY 32. NO TIME ASSIGNED TO CELIAS. 

REQUEST for 2 . 5 hours of HV commanding 

summary: STOF/SEM 0:00 hrs of command time 

CTOF 0 : 00 

MTOF 1:30 

09:00 - 09:30 MTOF WAVE to 12 kV (full operational voltaqe) 

10:30 - 11:00 MTOF HPS to 150 

12:00 - 12:30 MTOF HPS to 160 

12:30 - 13:30 EVALUATION command time. 

DAY 33. NO TIME ASSIGNED TO CELIAS. 

REQUEST for 2 hours of HV commanding 

summary: STOF/SEM 0:00 hrs of command time 



CTOF 

MTOF 


0:00 

1:00 


09:00 - 09:30 
10:30 - 11:00 
12:00 - 13:00 


MTOF Vf to +-1 kV {nominal voltage for 
first month of operations) 

MTOF HPS to 170 (nominal voltage for 
first month of operations) 

EVALUATION command time. 



From: MX% "pmartens@esa.nascom.nasa.gov" 29 -AUG- 1995 17:11:39.25 

To: MX%"galvin@umdsp.umd. edu" 

CC: 

Subj : Re: celias timeline revisions 

Return- Path : <pmartens@esa . nascom. nasa . gov> 

Received: from gsfc.nasa.gov by UMDSP.UMD.EDU (MX V4.0-1 VAX) with SMTP; Tue, 
29 Aug 1995 17:11:26 EDT 

Received: from esa.nascom.nasa.gov by gsfc.nasa.gov (5 . 65/Ultrix3 . 0-C) id 
AA03477 ; Tue, 29 Aug 95 17:11:44 -0400 

Received: from lion by esa (5 .x/SMI-SVR4) id AA10038; Tue, 29 Aug 1995 17:12:41 
-0400 

From: pmartens@esa.nascom.nasa.gov (Petrus C. Martens) 

Received: by lion (5.x) id AA01864; Tue, 29 Aug 1995 17:12:39 -0400 
Date: Tue, 29 Aug 1995 17:12:39 -0400 
Message-ID: <9508292112 . AA01864@lion> 

To: galvin@umdsp.umd.edu 

Subject: Re: celias timeline revisions 

X- Sun -Charset: US-ASCII 

Dear Tony, 

I am working on the CELIAS timeline, and I have the following 
questions/ comments : 

1. I did not get anything beyond block 2 or day 33. Did it get cut 
off, or are you still working on it? 

2. You will certainly get all the time you think you need. But what 

1 cannot guarantee is that you can have it at the days you want it, 
since there are competing demands on time by the other instruments. 

3. This (point 2) is why I prepared block- sheets (CELIAS Block 1 and 2 are 
appended) , which summarize all the task information, their durations, 
and their interrat ionships . I am putting all this information in 

the "Microsoft Project" scheduling tool, and let it produce a 
schedule. This allows me to check whether all the experiment requests 
can be met. It would also allow rapid rescheduling in the case of 
unexpected events after launch. (For example, if it turns out that 
MCC2 has to take place 14 days after launch instead of 20) . 

4. Please review the appended blocks for CELIAS with the above (point 3) 
in mind. I am not quite happy with their internal consistency. For 
example, why is "1.16 CT0F Initial Configuration" part of Block 1, 
while all other xTOF Initial Configurations are part of Block 2? 

Perhaps there should be a clearer delineation between Block 1 and 2. 

5. If MCC2 takes place at days 19-21, I think the appropriate break is 
indeed at the end of l . 13 . 

6. Normally I would not want to start Block 2 until Block 1 is completed. 

For CELIAS that would imply a delay of 2.1 until after MCC2 , but 

that would be a good idea anyway, since there is not much point 
in having "ST0F Intial Configuration" and then turning it off again 

2 days later for MCC2 . Objections? 

7. There is a problem with contigency. As you know normally 100% 
contingency is allowed for each task, and I will do the same for CELIAS. 
However, there are only 8 experiment reserved contact hours per day, 
and with full contingency that makes for only 4 hours of regular 



task time. Hence I get in trouble with the days where you request 
roore than 4:00, such as day 24, 25, 27-29. What do you suggest? 
Can you break down the tasks in smaller chunks (<= 4:00) so that 
I can reserve contingency on the same day? 

That's it. Please review the appended Block sheets, and feel free to 
correct/modify where needed -- it makes my life a lot easier. I will 
also append a brief Block sheet explanation at the end. If there are 
any explanations needed, you can also call at- 286-9028. 

Thanks a lot, 

Piet 

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 

COMMISSIONING PHASE BLOCK SHEET 

1. INSTRUMENT AND BLOCK NUMBER: CELIAS Block 1 

2. BLOCK IDENTIFICATION: CELIAS Early Switch-on 

3. PURPOSE: Early Switch-on and Bake-out to Avoid Contamination 

4. SUB -BLOCKS: 

NR. IDENTIFICATION 

1.1 DPU Turn-on and Check-out 


1.2 

MTOF 

Turn-on and Check-out 




1.3 

MTOF 

Cover Release 

and Bake -out 



1.4 

STOF 

and SEM Electronics Turn-on 



1.5 

STOF 

SSD Check-out 

(Closed) 



1.6 

MTOF 

Off and STOF ; 

Shutter 

Release 



1.7 

STOF 

SSD Checkout 

(Open) , 

MTOF return 


1.8 

STOF 

StartBakeout 




1.9 

CTOF 

Switch -on and 

SSD Check-out 



1.10 

CTOF 

IFC Check-out 





1.11 

CTOF 

Start Bake -out 




1.12 

STOF 

End Bake out 





1.13 

MTOF 

End Bake -out 





1.14 

CTOF 

End Bake -out 





1.15 

STOF 

Begin IFC Checkout 




1.16 

CTOF 

Initial Configuration 




1.17 

STOF 

End IFC 





5. SUB -BLOCKS 

TABLE: (see Note 2) 




NR. - 

DURATION - PREVIOUS - COMMANDING - 

TELEMETRY - POINTING 

1.1 

0:50 

N/A 

PRO, 

NRT-d 

H 

None 

1.2 

0:40 

Norn 

PRO, 

NRT-d 

H 

None 

1.3 

1:15 

Norn 

PRO, 

NRT-d 

H 

None 

1.4 

0:50 

Norn 

PRO, 

NRT-d 

H 

None 

1.5 

1:00 

Norn 

PRO, 

NRT-d 

H 

None 

1.6 

0:50 

Nom 

PRO, 

NRT-d 

H 

None 

1.7 

1:30 

Nom 

PRO, 

NRT-d 

H 

None 

1.8 

0:30 

Nom 

PRO, 

NRT-d 

H 

None 

1.9 

1:20 

Nom 

PRO, 

NRT-d 

H 

None 

1.10 

0:40 

Nom 

PRO, 

NRT-d 

H 

None 

1.11 

0:15 

Nom 

PRO, 

NRT-d 

H 

None 

1.12 

0:30 

1.8 

PRO, 

NRT-d 

H 

None 

1.13 

0:30 

1.3 

PRO, 

NRT-d 

H 

None 

1.14 

0:30 

1.11 

PRO, 

NRT-d 

H 

None 



4- NOV- 1995 17:17:47.02 


From: UMDSP::S0H0 

To: aF0T,aS0H0J>S 

CC : 3H0VESTADT “ aSOWG , SOHO 

Subj: memo on CELIAS - FOT meeting (2 Nov 95) 


TO: 


CC: 


Keith Walyus (FOT) 

Carline Cazeau (FOT) 

BRETT SAPPER (FOT, please forward, no e-mail address available) 

ROB SNELL (FOT, please forward, no e-mail address available) 


Vicente Domingo 
Art Poland 
Bill Worall 
Dieter Hovestadt 
Berndt Klecker 
Heiner Gruenwaldt 
Kay-U Reiche 
Fred Ipavich 
Martin Hilchenbach 
Peter Wurz 


(PS) 

CPS) 

(Ground systems, please forward, e-mail address unknown) 
(CELIAS PI) 

(Co- I) 

(CTOF Lead Co- I) 

(represents DPU Lead Co- I) 

(MTOF Lead Co- I) 

(STOP Lead Co- I ) 

(Bern Co- I representative) 


Dear Keith and Carline, 


There have been major discussions within the CELIAS team since our Thursday 
meeting as to how we can approach the CELIAS turn on situation. To 
recapitulate the situation, as of the meeting between the FOT (yourselves) 
and CELIAS (myself, Klecker, and Gruenwaldt): 


CELIAS COMMISSIONING 

All CELIAS commands that involve the DPU software patches, the 
MTOF and STOF wax motors (cover openings), high voltages for all 
sensors, and modes that affect high voltages in all sensors 
are "Disallowed for NRT" and a subset are also Critical comnands. 
Such commands cannot be sent by Near Real Time Commands from the 
IWS. The designation of "Not Allowed" and "Critical" are in the 
Project Data Base, and cannot be changed within any short time 
period, even if that were desirable. 

Critical commands can only be sent by FOT procedure. 

"Not Allowed" can be sent by RCR during an NRT session, if the 
predefined command sequence file exists. 

"Not Allowed" can be sent by FOT TSTOL procedure, if the procedure 
f i le exists. 

"Not Allowed" can technically be sent by Delayed command files, but 
that is usually inappropriate for high voltage commands at 
least during the initial commissioning. 

BINARY commands from NRT can bypass the above checks, however 
binary commanding is supposed to be disallowed on the 
CELIAS 1US. 

Consequently, CELIAS requires TSTOL and/or RCRs to accomplish 
commissioning. (Or the option of BINARY commanding would have 
to be re- considered. ) 

In order to help decrease the amount of time required to create 
the CELIAS procedures, the procedures were "pre- written" in 
TSTOL by the CELIAS representatives before submission to the FOT. 

The majority of these procedures were submitted by the (admittedly 
extended) deadline of October 13, 1995 (e-mail by Dan Muhonen 
to Pis, dated 11 Oct). 

There is a difficulty caused by the (1) late (relative to the 
launch date of 23 Nov) submission of the CELIAS commissioning TSTOL 
procedures and/or RCRs, (2) the nunber of such files submitted, and 
(3) an increased load on the FOT for SVM procedures at this time. 

It is well understood that s/c procedures take precedence over experiment 
procedures, although it is not clear that the FOT had been previously 
informed by Matra or had been aware as to how extensive this s/c load 
was going to be at this time before launch. I also imagine the 
creation of a new test (GSCT#4) affected the time available to the FOT. 

At the time of the meeting (2 Nov 95) between the FOT and the CELIAS 
representatives, none of the CELIAS procedures that had been submitted 
to the FOT approximately 25 days earlier had been acted upon, and it was 
felt by the FOT that there would be no time to implement any significant 
number until about 50 days or so after launch. The FOT indicated that 
no time would be saved by creating RCRs instead of TSTOL s. 

The cover opening for the MTOF on day 10 was of particular concern for 



the CELIAS representatives, as this involves critical commands, and 
a waiver for day 10 opening had previously been granted based on 
instrument well-being concerns. Therefore waiting 50 days after launch 
before being commissioning was not favorably received. 

However, the CELIAS representatives agreed to write new procedures, in 
particular for the high voltage turn on sequences (required after day 22), 
in a parameter input form, instead of hard-coded inputs. This would cut 
down dramatically the required number of procedures. 

The FOT will try to do experiment commissioning procedures if there is time, 
but no guarantees were, or could be, given. 

We were further asked by the FOT to submit a "what is needed by what day" 
list of procedures, or at least how many procedures are involved. We 
estimated at the meeting that the total number could be decreased to about 
50, with possibly 9-12 required by day 10. A better estimate is given at 
the bottom of this message. 

The attached list is based on the discussions (sometimes by phone or fax) 
by Galvin, Hovestadt, Klecker, Hilchenbach, Gruenwaldt, Ipavich. We 
realize the generation of this list by the CELIAS team does not guarantee 
implementation by the FOT. “ 


HEATERS. 

During the FOT-CELIAS meeting, a separate matter that concerns instrument 
operations was discussed. This regards the replacement (aka "non-ops", aka 
compensation") heaters. There are five separate units in the CELIAS experiment 
that have heaters. The DPU and STOF-Electronics box are collectively 
controlled thermally, and (unfortunately) the same commands are used to 
turn ON or OFF their separate heaters (CELIAS Heater A, and redundant Heater 
B). The CTOF, MTOF, and STOP are individually controlled, and have separate 
heater commands CELIAS Heater 1, 2, 3, respectively, plus a Heater 4 conmand 
that is the redundant heater command for all three. 

The current procedures for turning the CELIAS experiment heaters ON/OFF are 
based solely on the condition of the DPU. This is inappropriate. Obviously 
the DPU needs to be on before any sensor is turned on, but the sensor ON/OFF 
status is otherwise independent. The FOT needs to take into account that 
the sensor turn on wi l l be staggered. The DPU and MTOF are to be turned on 
on day 10. The DPU heater must be turned off once the DPU is on. (MTOF 
heater will be turned off for cover release, but then on again for bakeout.) 
Since the STOF-E heater is linked to the DPU heater by a camion 
command, STOF-E must also be turned on, on day 10, because it cannot be left 
off if its heater is off. CTOF will not turn on until day 15, so its heater 
must remain on. Etc., Etc. 

We also have permission to have the heaters on while sensors are on during 
the respective sensor BAKEOUT. So initially there will be times when 
both the sensor and its heater will be on. (Except only the STOF heater, 
and not the STOF-E heater would be on during STOF bakeout. Etc.) 

In other words, the heater situation should be scripted to minimize 
confusion. 

The FOT should be aware that the sensors ON/OFF state is controlled by 
CELIAS Block commands, which in fact are allowed through NRT, Delayed, 

TSTOL , etc. There are also conditions under the control of the DPU 
in which sensors may be powered off automatically (for exanple, this is 
an optional ESR response, and may also occur if the DPU watch dog is 
activated.) 

This issue has been brought up (by me) more than once at SOWG meetings, 
and I have been repeatedly assured that the heater control, 
which involves s/c commands, will be handled appropriately'without any 
required intervention by the experimenter. I am sinply re- ini terating 
this matter here, since it was not apparent that the FOT procedure used for 
preparation for experiment turn on recognizes this fact. 


Best regards, 
Toni Galvin 


************************* 



For day 10 after launch, the following CELIAS procedures will be required 
(this list was submitted to the FOT last week and is included for 
completeness * all procedures for day 10 have been submitted to the FOT): 


(1) fjf l_cls_on_p.prc 

(2) f_f l _pwrof_pr .prc 

(3) f_f l_d_lud_on.prc 

(4) f_f l_d__patch1 .prc 

(5) f_f l_d_patch2.prc 

(6) f_f l_d_patch3.prc 

(7) f_f l_d_patch4.prc 

(8) f_f Ijnjnodstb.prc 

(9) f_f l_m_modi fc.prc 

(10) f_f Ijnjnodof f .prc 

(11) f_f t_mp_hv0.prc 

(12) f_f l_m_wmt120.prc 

(13) f_f l jn_wmt180.prc 

(14) f_f l_m_wmt240.prc 

(15) f_f l_m_wmt300.prc 

(16) f_f ljn_wmtvar .prc 

(17) f_fl_standby 

(18) f_fl_stofman 

(19) f fl sem on 


CELIAS ON, PRIMARY (some corrections 
from f_f l_pwron_pr.prc) 

CELIAS OFF, PRIMARY (for contingency; 

this proc exists) 

DPU latch up det on 
DPU s/w patch 1 
DPU s/w patch 2 
DPU s/w patch 3 
DPU s/w patch 4 
MTOF standby mode 
MTOF ifc mode 

MTOF off mode (for contingency) 

MTOF HV off (for safety) 

MTOF wax motor 2min 

MTOF wax motor 3min 

MTOF wax motor 4min 

MTOF wax motor 5min 

MTOF wax motor parameter time 

STOF standby 

STOF manual 

SEM on 


For day 14 after launch, the following additional procedures wi l l be 
needed: 


(20) 

f_f l_ssd_ 1 202 . prc 

STOF solid state detector limit=202 
(this proc was submitted to the FOT 
last month) 

(21) 

f_f l_ssd_on . prc 

STOF SSD bias enable / ON 

(this proc was submitted to the FOT 

last month) 

(22) 

f_f l_ssd_s202 . prc 

STOF SSD level = 202 

(this proc was submitted to the FOT 

last month) 

(23) 

f_f l_stim_h.prc 

STOF/HSTOF TOF Stimulation ON 
(this proc was submitted to the FOT 
last month) 

(24) 

f_f l_stof_wax . prc 

STOF wax motor operation *** this 
procedure is a revised version of 
the earlier Oct submission, will replace 
the earlier submission, and is attached 
at the end of a separate message. *** 


For day 15 after launch, the following additional procedures will be needed: 


** (25) 

f jf l _c tjiw 1 6 . pr c 

CTOF wps limit by parameter ** new 
procedure attached at end of a 

** (26) 


separate message ** 

f_f l_ct_phvl1 .prc 

CTOF hvps limit by parameter ** new 


procedure attached at end a separate 
message ** 


For day 22 after launch, the following addtional procedures will be needed: 


** (27) f_f Ijmjnode.prc 
k * (28) f_f l_m_preamp.prc 

** (29) f_f l jd_ thresh. prc 

* (30) f_f l_m_mcp70 . prc 

* (31) f_f l_m_enable.prc 

* (32) f_f l_m_psgen.prc 


MTOF mode by parameter ** new 
procedure attached at end of a 
separate message ** 

MTOF preamp ON/OFF by parameter ** new 
procedure attached at end of a 
separate message ** 

MTOF PM threshold selection by parameter 
** new procedure attached at end of 
a separate message ** 

MTOF combined mcps proecedure to set 
delta/limit 70. * NOT YET WRITTEN * 

MTOF High voltage enable by parameter 
* NOT YET WRITTEN * 

MTOF High voltage power supply, level, 
limit, delta by parameter (Power 
Supply GENeric). * NOT YET WRITTEN * 


This will take us up to day 24, as regards procedures. Until the 
"parameter 11 procedures are all accounted for, I cannot make a definitive 
count, but the estimated count for up to day 33 is as follows 



UP TO DAY 24 


ADDITIONAL UP TO DAY 33 


TOTAL by 
SENSOR UNIT 


DPU 7 

CTOF 2 

HTOF 15 

STOP 8 


0 - 1 
7 

0 - 1 
21 


7 or 8 
9 

15 or 16 
29 


TOTAL 

CELIAS 32 28 or 30 60 or- 62 


STOF has an additional request for another 10 procedures to be used 
for commissioning but sometime after day 33. I am requesting 
clarification from MPE as to when these would be required. 



CELIAS TIMELINE V 4.0 


SOHO PAYLOAD COMMISSIONING 

CELIAS TIMELINE 

FOR THE FIRST 180 DAYS 


Submittal version 4.0 
21- JULY-1995 


(CELIAS REPRESENTATIVE: A.B. GALVIN) 



CELIAS TIMELINE V 4.0 


Revisions 


Version 

Date 

Change 

2.0 


First submittal version. 

3.0 

29.Nov.94 

Changes to CTOF timeline based on discussion with H. 
Griinwaldt in 9/94. 

Day 4: CTOF turn on either in standby or manual. 

Day 4: CTOF order for IFC and SSD tests reversed. 



Day 4-12: CTOF bakeout increased from 2 days to 7 
days. CTOF SSDs on for bakeout. 

All subsequent CTOF procedures delayed accordingly 
(+5 days). 



Day 12-14: CTOF MCP turn on changed to last 3 days. 



Day 12-180: Daily CTOF IFC commanding. 



Day 14: CTOF E/Q tests moved from day 9, and duration 
increased from 3 to 6 hours. 



Day 15: CTOF PAPS turn on moved to day 15 from day 
10. 

4.0 

21.Jul.95 

Experiment commissioning will not be allowed before 
day 14, because of s/c operations requirements. MTOF 
exempted to start on day 10. Timeline restructured 
accordingly. 



Changes to MTOF timeline based on discussion with 
F.M. Ipavich (4/95). Further revisions after discussion 
with FMI (7/95). 



Timelines for CTOF and STOF unchanged except shifted 
to new start date (day 14), based on discussion with F. 
Biirgi (5/95). 





notes: 

The scripts for individual procedures should be considered as top level information on the 
type of commands involved. Their primary purpose is to help make a better estimate on 
the "when" and "how long" required to perform a particular procedure. The detailed 
procedure scripts are under development. 
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CELIAS TIMELINE V 4.0 


Abbreviated TIMELINE: 

DAY 00 + 1H to DAY 04: Lift Off and Spacecraft Operations. 

COMMENCE CELIAS THERMAL CONTROL. 

Thermal monitoring of CELIAS units ASAP. Non-ops 
heaters for CELIAS units should be turned on as soon as 
possible, but subject to temperature limits constraints. 

DAY 04-13: Spacecraft Operations only, except for some exemptions 

for specific experiments. Continue CELIAS thermal 
control. 

DAY 10: CELIAS DPU TURN ON, CHECKOUT, and S/W 

CONFIGURATION. 

CELIAS DPU turn on and checkout for the first time. 
Implement DPU flight configuration (including any 
software patches). 

MTOF TURN ON, CHECKOUT, and COVER 
RELEASE. 

MTOF turn on for the first time. 

MTOF initial checkout (IFC TEST). 

Preparation of CTOF, STOF, and MTOF for MTOF 
cover release. 

MTOF cover release. 

CELIAS reconfiguration after MTOF cover 

release (DPU and MTOF commands, if 
needed). 

Commence MTOF bakeout for at least 5 days (MTOF in 
Standby, non-ops heater on). 

DAY 14: STOF TURN ON, CHECKOUT, and SHUTTER 

RELEASE. 

STOF turn on for the first time. 

STOF initial checkout (SSD TEST); SSDs on. 

STOF initial checkout (IFC TEST). 

Preparation of CTOF, MTOF, and STOF for STOF 
shutter release. 

STOF shutter release. 

STOF reconfiguration after STOF shutter release. 
Commence STOF bakeout with SSDs on (at least 2 
days). 

MTOF reconfiguration after STOF shutter release. 

DAY 14 or 1 5 : CTOF TURN ON AND CHECKOUT. 

CTOF turn on for the first time. 

CTOF initial checkout (SSD TEST); SSDs on. 

CTOF initial checkout (IFC TEST). 

Commence CTOF bakeout with SSDs on (about 
one week). 
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CELIAS TIMELINE V 4.0 


DAY 16: 
Day 1 6 or 
DAY 17: 


DAY 18: 


DAY 19: 


END BAKEOUT FOR MTOF and STOF. 

Turn off MTOF non-ops heater. 

Turn off STOF non-ops heaters. 

17: SET STOF, MTOF INITIAL CONFIGURATION. 

Configure various MTOF rate, PHA, etc. definitions. 

Configure various STOF rate, PHA, etc. definitions. 

MTOF HIGH VOLTAGES - MCPs. 

MTOF MAIN Start MCP initial turn on (up to 

750v/plate, in six steps: 0, 60, 90, 1 10, 

120, 125. Wait at least 15 minutes between 
step commands for evaluation). 

MTOF MAIN Ion MCP initial turn on (up to 

750v/plate, in six steps, with at least 15 
minutes between step commands. 

MTOF MAIN Neutral MCP initial turn on (up to 

750v/plate, in six steps, with at least 15 
minutes between step commands). 

MTOF PM MCP initial turn on (up to 

750v/plate, in six steps, with at least 15 
minutes between step commands). 

SEM INITIAL TURN ON. 

STOF HIGH VOLTAGES - MCPs. 

STOF MCP1 initial turn on. 

STOF MCP2 initial turn on. 

MTOF HIGH VOLTAGES - MCPs and PM E/Q. 

MTOF MAIN & PM MCPs bias increase in six (or less) 
steps, at least 30 minutes between steps. 
Bring to Nominal Operational Levels: 

Start MCP to 145, 

Neutral MCP to 140, 

Ion MCP to 155, and 
PM MCP to 140. 

Commands for Start, Ion, Neutral and PM 
MCPs can run concurrent. 

MTOF PM E/Q initial turn on (3 max levels: lkV, 2kV, 
and 3k V limits). Time between new max 
level commands at least 15 minutes. 

STOF HIGH VOLTAGES - MCPs. 

STOF MCP1 bias increase. 

STOF MCP2 bias increase. 

END CTOF BAKEOUT. 

Turn off CTOF non-ops heater. 

PRE-MANUEVER PREPARATION. 

CTOF preparation for MCC2 (HV-off, standby). 

MTOF preparation for MCC2 (HV-off, standby). 

STOF & SEM preparation for MCC2 (HV-off, standby). 
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CELIAS TIMELINE V 4.0 


DAY 20-22: 

DAY 22 and/or 23: 


DAY 23 or 24: 
DAY 24 


DAY 25: 


DAY 26: 


S/C MANUEVERS - MCC2. 

POST-MCC2 MANUEVER RECONFIGURATION. 

Reconfigure MTOF (turn on MCPs as on 

Day 17 and PM E/Q as on Day 18). 
Reconfigure STOF/SEM. 

Reconfigure CTOF. 

CTOF HIGH VOLTAGE - MCPs. 

CTOF MCPs initial turn on. 

CONTINUE POST-MCC2 MANUEVER 
RECONFIGURATION. 

MTOF MCPs reconfiguration continued, as on Day 18. 
STOF MCPs reconfiguration continued. 

CTOF HIGH VOLTAGES - MCPs, E/Q. 

CTOF MCPs bias increased. 

CTOF E/Q initial turn on. 

CTOF PERMANENT COMMANDS. 

CTOF daily IFC test (for life of mission). 

STOF HIGH VOLTAGES - HSTOF E/Q, STOF E/Q. 
HSTOF E/Q initial turn on. 

STOF E/Q initial turn on. 

MTOF HIGH VOLTAGES - HPS, PM. 

MTOF Hyperbola initial turn on (level 0, 50, 80 with 
30 minutes between each level increase). 
MTOF PM E/Q limit increased to 4 kV. 

MTOF HIGH VOLTAGES - WAVE E/Q, HPS. 

MTOF MAIN WAVE E/Q initial turn on (to 4 kV). 
MTOF HPS voltage increase (at least 30 minutes after 
WAVE turn on, set HPS to level 90. Wait 
at least 30 more minutes, set HPS to 100). 

CTOF HIGH VOLTAGES - PAPS. 

CTOF PAPS initial turn on. 

MTOF HIGH VOLTAGES - WAVE E/Q, HPS. 

MTOF MAIN WAVE E/Q increase (to 6kV). 

MTOF HPS voltage increase (at least 30 minutes after 
WAVE increase, set HPS to level 110. 

Wait at least another 30 minutes, set HPS 
to level 120). 

CTOF HIGH VOLTAGES - PAPS. 

CTOF PAPS voltage increase. 
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CELIAS TIMELINE V 4.0 


day 27 : MTOF HIGH VOLTAGES - WAVE E/Q, HPS. 

MTOF MAIN WAVE E/Q increase (to 8 kV). 

MTOF HPS voltage increase (at least 30 minutes after 
WAVE increase, set HPS to level 130). 

CTOF HIGH VOLTAGES - PAPS. 

CTOF PAPS voltage increase. 

DAY 28: MTOF HIGH VOLTAGES - WAVE E/Q, HPS. 

MTOF MAIN WAVE E/Q increase (to 10 kV). 

MTOF HPS voltage increase (at least 30 minutes after 
WAVE increase, set HPS to level 140). 

CTOF HIGH VOLTAGES - PAPS. 

CTOF PAPS voltage increase. 

DAY 29: MTOF HIGH VOLTAGES - WAVE E/Q, HPS. 

MTOF WAVE set to full operational voltage (limit to 
max kV). 

MTOF HPS voltage increase (at least 30 minutes after 
WAVE increase, set HPS to level 150. 

After at least another 30 minute wait, set 
HPS to level 160). 

CTOF HIGH VOLTAGES - PAPS. 

CTOF PAPS voltage increase. 

DAY 30: MTOF HIGH VOLTAGES - Vf, HPS. 

MTOF MAIN Vf initial turn on (limit ±lkV). 

MTOF HPS voltage increase (at least 30 minutes after 
Vf turn on, set HPS to level 170). 

DAY 50: MTOF HIGH VOLTAGES - Vf, HPS. 

MTOF Vf and/or HPS: Possible voltage increase, 
at the discretion of the experimenter. 

DAY 59: CELIAS CONFIGURATION FOR S/C HGA OUT 

OFFOV 

DAY 60: S/C HGA OUT OF FOV. NO P/L COMMANDING. 

DAY 62 CELIAS RECOVERY PROCEDURES. 

CTOF HV RECOVERY. 

MTOF HV RECOVERY - DAY 1. 

STOF HV RECOVERY. 

DAY 63 CELIAS RECOVERY PROCEDURES CONTINUE. 

MTOF HV RECOVERY - DAY 2. 

DAY 64 CELIAS RECOVERY PROCEDURES CONTINUE. 

MTOF HV RECOVERY - DAY 3. 
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CELIAS TIMELINE V 4.0 


DAY 70: 

DAY 75: 

DAY 76: 

DAY 77: 

DAY 78 
DAY 79 
DAY 90: 

DAY 110: 

DAY 1 14: 

DAY 115-119: 
DAY 120: 

DAY 121: 
DAY 122: 
DAY > 120: 


MTOF HIGH VOLTAGES - Vf, HPS. 

MTOF Vf and/or HPS: Possible voltage increase, 
at the discretion of the experimenter. 

CELIAS CONFIGURATION FOR S/C 
MANUEVERS - TBD 

OFF-LOADING OF REACTION WHEELS - P/L in 
STANDBY. 

CELIAS RECOVERY PROCEDURES. 

CTOF HV RECOVERY. 

MTOF HV RECOVERY - DAY 1 . 

STOF HV RECOVERY. 

CELIAS RECOVERY PROCEDURES CONTINUE. 
MTOF HV RECOVERY - DAY 2. 

CELIAS RECOVERY PROCEDURES CONTINUE. 
MTOF HV RECOVERY - DAY 3. 

MTOF HIGH VOLTAGES - Vf, HPS. 

MTOF Vf and/or HPS: Possible voltage increase, 
at the discretion of the experimenter. 

MTOF HIGH VOLTAGES - Vf, HPS. 

MTOF Vf and/or HPS: Possible voltage increase, 
at the discretion of the experimenter. 

CELIAS PREPARATION FOR HOI MANUEVERS. 

CTOF preparation for HOI (HV-off, standby) 

MTOF preparation for HOI (HV-off, standby) 

STOF & SEM preparation for HOI (HV-off, standby) 

S/C MANUEVERS for HOI 

CELIAS RECONFIGURATION AFTER HOI. 

CTOF reconfiguration after HOI 
MTOF reconfiguration after HOI 
STOF & SEM reconfiguration after HOI 

CELIAS RECONFIGURATION AFTER HOI 
CONTINUES 

MTOF High Voltage turn on continued. 

CELIAS RECONFIGURATION AFTER HOI 
CONTINUES 

MTOF High Voltage turn on continued. 

S/C IN HOP: THRUSTER OPERATIONS 
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From: 16136: :CST "CHRIS ST. CYR, GSFC/682/ATSC/SOHO, 301/286 - 8968 " 30-NO 

To: UMDSP: : GALVIN 

CC: 

Subj : Can you help me out here Toni? We need a CELIAS response. Thanks! 

TO: D. Muhonen, B. Worrall 

FROM: C. St_. Cyr 

DATE : 3 0 Nov 9 4 

RE: Critical Commands for Instruments ~ 

CC : SOWG 

I have gathered information from the experimenters about the commands 
which are presently marked as "critical" or "hazardous" in the SDB. 

The responses varied from instrument- to- instrument , and this memo will 
document each case. 

There are some instrument commands in the SDB marked as "critical" or 
"danger", and this designation will be carried through to NASA's PDB 
unless the PI team notifies the FOT that the flag should be 
removed for flight. Nominally, when a "critical" command appears in a 
TSTOL Procedure or is typed in at the POCC console, then a second "SEND" 
or "ALLOW" command is required by the FOT to execute transmission to the 
spacecraft . 

The NASA PDB has an additional field called "Not Allowed for NRT 
Commanding". At this time, only those commands in the SDB which were 
marked "critical" have this additional flag set. The purpose of this 
field was to provide another level of security to the PI teams in case 
there were any OBDH Block Commands which they did not want declared as 
"critical", but which they also did not want issued from the EOF. 

Recall that only OBDH Block Commands can be sent from the EOF. 

What happens if one of these "Not Allowed for NRT Commanding" OBDH Block 
Commands is sent from an IWS in the EOF? We assume that the IWS is 
authorized to command that instrument, that the syntax is correct, etc. 

If the command is sent in mnemonic form, it will be rejected by the Command 
Management System (CMS) in the SMOCC. No further commanding of that 
instrument can take place from the EOF until the instrumenter acknowledges 
the error. 

But what if such a command is sent in Binary format? There is really no 
way for any element in the ground system to recognize and stop such a 
command. We have always stated that Binary commanding put the burden of 
responsibility completely on the PI team, and we now know how each 
team plans to provide the insurance to prevent that. Below are the list 
of commands for each instrument that are currently marked as "critical" 
and the response of each PI team to this question: 


- - - CDS - - - 
CB3RESET 

*F Soft reset 

CDHS BK 


CBEFILE 

Filament Pw enable (isola relay) 

BK 

CBEFILN 

Filament on 

BK 


CBEGHV1N 

GIS HV1 on 

BK 


CBEGHV2N 

GIS HV2 on 

BK 


CBEGHV3N 

GIS HV3 on 

BK 


CBEGHV4N 

GIS HV4 on 

BK 


CBEGHVE 

GIS HV enable 

(isolation relay) 

BK 

CBEHTRSN 

Op Heaters on 

BK 


CBEVHTRN 

VDS Heater on 

BK 




CBEVHVN 

VDS HV power 

supply 

on 

CBGHV1E 

HV1 enable 

BK 


CBGHV1V 

HV1 set 

BK 


CBGHV2E 

HV2 enable 

BK 


CBGHV2V 

HV2 set 

BK 


CBGHV3E 

HV3 enable 

BK 


CBGHV3V 

HV3 set 

BK 


CBGHV4E 

HV4 enable 

BK 


CBGHV4V 

HV4 set 

BK 


CBGLRB 

Rebuild lookup 

table 

BK 

CBGMCP1L 

Limit for HV 

1 cur 

BK 

CBGMCP2 L 

Limit for HV 

2 cur 

BK 

CBGMCP3L 

Limit for HV 

3 cur 

BK 

CBGMCP4L 

Limit for HV 

4 cur 

BK 

CBGRESET 

Reset everything 

BK 

CBGSFTRS 

Soft proc. reset 

BK 

CBMDGOS 

Door GIS open 

( solenoid ) 

CBMDVOS 

Door VDS open 

( solenoid ) 

CBV Send any command 

BK 



These commands were flagged for instrument -level and spacecraft -level 
AIV activities. Many of them will be removed from the "critical" list. 
During NRT commanding, mnemonics which are sent by the 
IWS operator are checked against a CDS- specific database on the IWS, 
and any commands which the PI team chooses to leave as "critical" after 
AIV will be flagged so that the operator has to perform a "safety" step. 
For protection against one of these commands being produced in a Binary 
load, any hazardous commands are flagged during the generation of 
the load. (Jeff Payne) 


LASCO/EIT 


EBEDOP 

EIT Aperture Door OPEN 

BK 

EBEDPA 

EIT Door PA FIRE 

BK 


EBEVPA 

EIT Depres Valve 

PA FIRE 

BK 

LB1D0P 

Cl Aperture Door 

OPEN 

BK 

LB1DPA 

Cl Door PA FIRE 

BK 


LB2D0P 

C2 Aperture Door 

OPEN 

BK 

LB2DPA 

C2 Door PA FIRE 

BK 


LB3D0P 

C3 Aperture Door 

OPEN 

BK 

LB3DPA 

C3 Door PA FIRE 

BK 


LBCLPA 

COB Launch Lock PA FIRE 

BK 


LBPXON Prom Card Power ON, REBOOT BK 

LBSBOOT PCE Processor BOOT BK 

Only the Paraffin Actuator commands will remain marked as "critical" 
for flight. Those commands will be double -password protected for 
use as mnemonics, and they will be excluded from the Binary load 
generation software. (Russ Howard) 


---CELIAS 

FBDBRK Break . BK 

FBDCONT Continue. BK 

FBDFM Fill Memory. BK 

FBDMM Modify Memory. BK 

FBDMPB Modify Port Bytes. BK 

FBDMPW Modify Port Word. BK 

FBDRUN Run From BK 

FCPWRAN DPU main power 


DHPC 



From: UMDSP: : GALVIN "Toni Galvin (Univ. Md) " 30-NOV-1994 15:41:47.83 

To : @TUB 

CC : @BUERGI , MPE : : BEK , GALVIN 

Subj : critical commands 

Dear Kay-U, 


I need to know whether or not you want any dpu related commands 
listed as critical for SOHO. Right now, the only commands listed 
as critical have to do with sensors -- on/off, high voltages, etc. 

I sent a list of the Matra data base commands back to TUB with 
Thomas. (This is the same as an earlier e-mail from a few months ago, 
plus I will send a similar one after this memo.) For example, should 
things like FBDMM = modify memory be a critical command? Because right 
now it is not on my list. Or "modify port byte", "modify register", etc? 

I need to get this done this week, as I am leaving for Toulouse on 
Sunday. So the default will be my existing list: 

FCPWRAN 

FCPWRAR 

FCPWRBN 

FCPWRBR 

FCMPBTN 

FCMPBTR 

Since these are all ooc commands, I do not think we could send them 
even if we wanted to. 

Is there any documentation on what the CELIAS commands are, and 
what they do, and what the parameter input should be? All I have 
are the Matra data base command/ tel erne try list. It would certainly 
make my job easier if I could get a copy of the DPU command definition 
document, if such exists. 


best regards, Toni 



From: UMDSP: : GALVIN "Toni Galvin (Univ. Md) " 4 -DEC- 1994 14:13:33.32 

To: SDAC : : CST 

CC: @CRIT, GALVIN 

Subj : celias critical command list for flight 

To : Chris StCyr 

CC : Buergi, Hovestadt, Hilchenbach, Ipavich, Bedini, Gruenwaldt, Reiche 


Dear Chris, 

Here is the CELIAS critical command list for flight operations 

best regards, 

Toni Galvin 


CELIAS Critical Commands for Flight 
Sensor TC 

DPU FCPWRAN 

FCPWRAR 
FCPWRBN 
FCPWRBR 
FCMPBTN 
FCMPBTR 

CTOF FBCM0D2 

FMCM0D2 I 
FBCM0D3 
FBCM0D3I 
FBCM0D4 
FBCM0D5 
FBCM0D6 
FBCENA 
FBCLIMHV 
FBCLIMMC 
FBCLIMW 
FBCHVPS 
FBCMCPS 
FBCWPS 
FBCCTRL 


♦same as Sep 94 Toulouse list* 


♦same as Sep 94 Toulouse list* 


MTOF FBMM0D5 
FBMM0D6 
FBM0PT1 
FPM0PT2 
FBMLIMPM 
FBMLIMPE 
FBMLIMWE 
FBMLIMVF 
FBMLIMSM 
FBMLIMNM 
FBMLIMIM 
FBMLIMHV 
FBMENA 
FBMENAI 


♦slightly revised from Sep 94 Toulouse list * 
* as there are fewer MTOF critical commands * 



FBMPM 

FBMPE 

FBMWE 

FBMVF 

FBMSM 

FBMNM 

FBMIM 

FBMHV 


STOF FBSM0D2 *same as Sep 94 Toulouse list* 

FBSM0D2 I 
FBSMOD3 
FBSM0D3I 
FBSMOD4 
FBSMOD5 
FBSPWR 
FBSEUVON 
FBSOPT1 
FBS0PT2 
FBSLIMSL 
FBSLIMSH 
FBSLIMHD 
FBSLIMM1 
FBSLIMM2 
FBSLIMBI 
FBSENA 
FBSENAHD 
FBSENASS 
FBSENAMB 
FBSENASB 
FBSHDON 
FBSSION 
FBSS20N 
FBSMBON 
FBSSBON 
FBSSWV 
FBSHDV 
FBSM1V 
FBSM2V 



From: UMDSP::SOHO 28-SEP-1995 16:40:15.29 

To: 3CAZEAU 

CC: 3H0VESTADT , SOHO 

Subj: request for PDB revisions 

Dear Carline, 

Kay Reiche has reviewed the command data base for CELIAS/DPU, and has 
found 13 command mnemonics that have an erroneous binary translation. 

I realize that you have not yet set up procedures for making changes 
to the PDB, and that Version 9 has not yet settled in. But once revisions 
to what will become Version 10 begin, please make the following corrections. 

What is given below is (1) the current data base with the WRONG values 

(2) the revised data base with the CORRECT values 

Please note that 7 of the commands that require revision are designated 
as "CRITICAL 11 in the database, and therefore we are most anxious to have the 
mnemonic TC available. Once you have determined the procedure for making 
changes in the PDB, I would appreciate an estimate on when the revisions 
will be implemented. 


Best regards, 
Toni Galvin 


P.S. I am working under the assumption that Matra has transferred 
responsibility for future data base changes to the FOT . If Matra 
needs to be contacted regarding these changes, please let me know. 


(1) All of the following commands are currently wrong in the database 
(the first words (0100, 0200...) must be swapped (0001, 0002...)): 


mnemo description parameters (this version is wrong) 


fbdmm 

modify memory 

<11> 

0100 


(28 * 

* xxxx) 

fbdfm 

fill memory 

<11> 

0200 

xxxx 

xxxx 

xxxx 

xxxx 

fbddpb 

display port byte 

<11> 

0300 

xxxx 




fbdmpb 

modify port byte 

<11> 

0400 

xxxx 

0000 

0000 

xxxx 

fbddpw 

display port word 

<11> 

0500 

xxxx 




fbdmpw 

modify port word 

<11> 

0600 

xxxx 

0000 

0000 

xxxx 

fbddr 

display registers 

<11> 

0700 





fbdmr 

modify register 

<11> 

08xx 

0000 

0000 

0000 

xxxx 

fbddbp 

display breakpoints 

<11> 

0900 





fbdmbp 

modify breakpoint 

<11> 

Oaxx 

xxxx 

xxxx 



fbdrun 

run from 

<11> 

ObOO 

xxxx 

xxxx 



fbdbrk 

break 

<11> 

OcOO 





fbdcont 

continue 

<11> 

OdOO 






(2) The requested revisions 


parameters (this version is correct) 


mnemo description 


fbdmm modify memory 
fbdfm fill memory 
fbddpb display port byte 
fbdmpb modify port byte 
fbddpw display port word 
fbdmpw modify port word 
fbddr display registers 
fbdmr modify register 
fbddbp display breakpoints 
fbdmbp modify breakpoint 
fbdrun run from 
fbdbrk break 
fbdcont continue 


<11> 

0001 

.... 

(28 * xxxx) 

<11> 

0002 

xxxx 

xxxx 

xxxx 

xxxx 

< 11 > 

0003 

xxxx 




< 11 > 

0004 

xxxx 

0000 

0000 

xxxx 

< 11 > 

0005 

xxxx 




< 11 > 

0006 

xxxx 

0000 

0000 

xxxx 

<11> 

0007 





<11> 

xx08 

0000 

0000 

0000 

xxxx 

<11> 

0009 





<11> 

xxOa 

xxxx 

xxxx 



<11> 

000b 

xxxx 

xxxx 



<11> 

000c 





<11> 

OOOd 










From: UMDSP:;SOHO 18-0CT-1995 16:31:55.15 

To: aCAZEAU 

CC: 3H0VESTADT , QBORNEMANN, IPAVICH,SOHO 

Subj: another cel i as database change request 

Dear Carline, 

I asked my colleagues to make another check on the command 
data base for CELIAS, and my STOF colleagues may have found 
another error in the command base, although I am not sure 
if they really are looking at version 9 or not. I am 
attaching the e-mail I received today from Walter Bornemann, 
and at some point I hope the FOT can check it out. 

Will the corrections that are so sorely needed in the DPU 
commands be implemented in time for the GSCT#4? It will 
affect what needs to be done via binary vs. mnemonic. 

I have additional delays from the CTOF Lead Co- I concerning 
his procedures. I suspect it will be a few more days. 

best regards, Toni Galvin 

p.s. Please give my continuous apologies to Brett 

p.s.s I will be out of town all next week, which hopefully will 

not matter. 


***** attached message regarding STOF command ****** 

Dear Toni, 

thanks for your promt response concerning the Goddard database. 
During the check of the Matra database version 9 we found out, that 
they have forgotten to change one of the STOF commands. The command 
named FBSSMPL has too few parameters (4 bytes instead of 6). 

Correction for the FBSSMPL command: 


old new 


CK 

FBSSMPL 

1 

1054 

FFFF 

CK 

FBSSMPL 

1 

1054 

FFFF 

CK 

FBSSMPL 

2 

0000 

0000 

CK 

FBSSMPL 

2 

0000 

0000 

CK 

FBSSMPL 

3 

0000 

0000 

CK 

FBSSMPL 

3 

0000 

0000 






CK 

FBSSMPL 

4 

0000 

0000 


(part of the SOHOCK.PDB file) 


Please can you give the corrected FBSSMPL command to the FOT team to 
implement this together with the database 9. Can you additionally 
check whether all changes in the database 9 are implemented by the 
FOT (including the changes written by hand at KSC, e.g. STOF sweep 
housekeeping calibration curve). 


bye,Wal ter 



From: MX% "vdomingo@so . estec . esa . nl " 19 -DEC- 1994 07:52:29.21 

To : GALVIN 

CC: 

Subj : Minutes SOWG meeting 18 Nov 1994 

Return- Path : <vdomingo@so . estec . esa . nl > 

Received: from bcserver.estec.esa.nl by UMDSP.UMD.EDU (MX V4.0-1 VAX) with 
SMTP; Mon, 19 Dec 1994 07:52:26 EST 

Received: from dove.so.estec.esa.nl by bcserver.estec.esa.nl (AIX 3.2/UCB 
5.64/4.03) id AA25629; Mon, 19 Dec 1994 13:52:30 +0100 
From: vdomingo@so.estec.esa.nl 

Received: from lynx by dove.so.estec.esa.nl (5 . 0/SMI-SVR4) id AA06175; Mon, 
Dec 1994 13:53:28 --100 

Received: by lynx (5.0) id AA14496; Mon, 19 Dec 1994 13:53:13 --100 
Date: Mon, 19 Dec 1994 13:53:13 --100 
Message- ID: <9412191253 . AA14496@lynx> 

To: cdp@astrol.bnsc.rl.ac.uk, galvin@umdsp.umd.edu 
Subject: Minutes SOWG meeting 18 Nov 1994 
X -Sun- Charset : US -ASCII 
Content -Length: 11298 

Minutes of the SOWG meeting held on November 18, 1994 at the SOHO EOF, 
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Goddard Space Flight Center. 
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To: attendees and members of SOWG 

copy: SWT, PI' 2s, ESA/NASA Ops Distribution 

15 December 1994 


ACTION ITEMS: 

AI 1 on Sanchez: To develop the format of the 'As-run' file. 

AI 2 on St.Cyr: To study the POCC retransmission logic in order to 
fine-tune it and get better NRT commanding response times. 

AI 3 on St.Cyr: To find out why binary commands with wrong 
check-sums are accepted by the ground segment. 

AI 4 on the Project Scientist Office: To produce the image tool for 
synoptic data before the next simulation. 

AI 5 on PSO: to produce and distribute the SIM report by December 2, 
1994. = Closed on 8 December 

AI 6 on Pis: to report at the SWT meeting on Jan 24 on the status of 
the software for science planning and command load generation. 


1. AGENDA 

- Review of the results of the technical tests. 

- Current status and future plans. 


2. REVIEW OF THE RESULTS OF THE TECHNICAL TESTS 



(Viewgraphs presented by Chris St.Cyr to the SOWG) 
Simulation Philosophy 


o Two Parallel Goals of First SOHO Simulation 

- Functional Test of EOF. 

- Science Planning Simulation. 

o Functional Test Matrices 
o Discrepancy Reports. 

o Project Scientists' Discussions with Each PI Team. 


Overview of PI Team Functional Testing 


o Previous Months (February - October) 

- One Week Individual Testing of Instrument Workstations (IWS) . 

o Previous Week (7 Nov - 11 Nov) 

- Eight (8) IWS Configured. 

o Monday (14 Nov) 

- Four (4) Additional IWS Configured 

- Medium Rate Telemetry to All IWS (8 hours) 

- One MDI-M (5 minutes) session 

o Tuesday (15 Nov) 

- Medium Rate Telemetry (8 hours) 

- Two Near -Real -Time (NRT) Commanding (each 1.5 hours) Individual 
IWS Sessions 

- Two MDI-M (5 minutes) sessions 

o Wednesday (16 Nov) 

- Low Rate Telemetry (15 minutes) 

- Medium Rate Telemetry (8 hours + evening) 

- Two Near-Real-time (NRT) Commanding (each 1.5 hours) Individual 
and Group Sessions. 

- One MDI-M (1 hour) session 

o Thursday (17 Nov) 

- Low Rate Telemetry (15 minutes) 

- Medium Rate Telemetry (8 hours + evening) 

- Two Near -Real -time (NRT) Commanding (each 2 hours) Group IWS 
Sessions 

- One MDI-M (1 hour) session 

o Friday (18 Nov) 

- Low Rate Telemetry (15 minutes) 

- Medium Rate Telemetry (45 minutes) 

- One Near-Real-time (NRT) Commanding (45 minutes) Group IWS Session 


Personnel 



Project Scientists' Office 

ECS Developers 

CDS 

CELIAS 

CEPAC 

EIT 

GOLF 

LAS CO 

MDI 

SUMER 

SWAN 

UVCS 

Total 


Functional Test Successes 


o Telemetry Distribution 

- Real-time, Quick- look, Archived, and MDI-M 

o Commanding 

- Delayed Commands (VIRGO, EIT do not participate) 

- Near- Real -Time (NRT) (CEPAC, VIRGO, EIT do not participate) 

- Background Queue 

CDS, LASCO, SUMER, UVCS participated 
MDI and GOLF have unresolved CMS questions 

o Ancillary Data Products 

- Summary Data 

Provided by CDS, EIT, MDI, SUMER, UVCS 
LASCO did not submit 

- Input to Activity Plan 

CDS, EIT, LASCO, MDI, SUMER, UVCS 

- As -Run File 

Preliminary input provided by CDS and UVCS 
EIT, LASCO, MDI, SUMER did not submit 

o Other EOF Functions 

- E-mail 

- NASA Science Internet 

- Network Time Services 

- Informational Messages 


Unexpected Results 


o Ground system performed as specified when NRT commanding rate was 
much higher than anticipated. 

o Ground system performed well with 1 hour of MDI-M. 


Discrepancies 



o Telemetry 



- Only SWAN, GOLF, MDI have valid POCC displays. 

- Low Rate EXPHK packet had 12 byte offset. 

- Transmission of archived telemetry to IAC showed time-out 
error, but data appeared correct. 

- Automated distribution of Q/L files to IWS produced some 
duplicate copies. 

- VIRGO Q/L data not available. 

- ECS file-naming convention will not work for times when fill 
packets are present. 

- MDI-M sessions were 5 minutes but were advertised to be 15 
minutes . 

- UVCS final packet in Q/L had extraneous data. 

- Time offset initially between HK and SC packets. 

- CDS reported 4 minute 'hiccup' in medium rate. 

o Commanding : 

- Delays in NRT due to POCC retransmission logic. 

- Vague Error Messages from CMS in both Validation Reports and 
during NRT. 

- Incorrect SUMER (2) , LASCO (1) , CELIAS (1) commands passed 
through ground system. 

- CELIAS exceeded maximum size of Delayed Command File. 

- GOLF and MDI have unresolved CMS failures in Background Queue 
commanding . 

- UVCS reported non-reproducible RCR failure, 
o Other: 

- Several unexplained crashes of IWS, ECS, CMS, POCC computer 
systems . 


Future Testing Required 


o Telemetry Submodes (Flexible Bit Rate) not tested. 

o Some NRT functionality was partially tested: 

- Critical command mnemonics tested only by CELIAS. 

- Only UVCS used Remote Command Request (RCR) . 

- Only MDI, SWAN, UVCS used Remote Procedure Request mechanism 
(RPR) . 

- Only CDS and UVCS used Reserved Time . 

- ECS Command Status Display not implemented by CELIAS, EIT, 
SUMER, UVCS. 

o NRT Priority Levels not tested, 
o NRT Channel needs to be optimized. 

o Some Ancillary Data Products not available. 

- Orbit & Attitude, Command History File, Time Correlation 
File, SOHO Daily Report. 

o Activity Plan requires further work. 

o Use of 'overflow' area. 

o Electronic Security measures not implemented. 



MX% "vdomingo@so.es tec. esa.nl" 2-FEB-1995 17:15:52.78 

MX%"cdp@astrol .bnsc. rl .ac.uk" , MX% "galvin@umdsp.umd.edu" , MX% " ifkki . dnet 
SOWG meeting 
Return- Path : <vdomingo@so . estec . esa . nl > 

Received: from dove (dove.so.estec.esa.nl) by UMDSP.UMD.EDU (MX V4.0-1 VAX) 
with SMTP; Thu, 02 Feb 1995 17:15:45 EST 
Received: from lynx by dove with SMTP id AA14719 (5 . 67b+/IDA- 1 . 5 ) ; Thu 2 Feb 
1995 23:15:15 +0100 

Received: by lynx id AA06152 (5 . 67b+/lDA- 1 . 5 ) ; Thu, 2 Feb 1995 23:12:38 +0100 
Date: Thu, 2 Feb 1995 23:12:38 +0100 
From: Vicente <vdomingo@so . estec . esa . nl> 

Message -ID: <199502022212 . AA06152@lynx> 

To: cdp@astrol.bnsc.rl.ac.uk, galvin@umdsp.umd.edu, 

ifkki . dnet ! mueller_m@estgtw . estec . esa . nl , gurman@uvsp . gsf c . nasa . gov, 
lumme@sara . cc . utu . f i , grec@ayalga . unice . f r , howard@maple . nrl . navy . mil , 
rbush@solar.stanford.edu, 

nsp. dnet ! iaslab . dnet ! lemaire@estgtw. estec . esa . nl , 

Walter.Schmidt@fmi.fi, vanballe@cfa.harvard.edu, ajm@iac.es, 
poland@pal.gsfc.nasa.gov, cst@sdac.gsfc.nasa.gov, 
bf leck@so . estec . esa . nl , pmartens@so . estec . esa . nl , 
lsanchez@so . estec . esa . nl , elarduinat@ess -mail . atsc . allied . com, 
vdomingo@so.estec.esa.nl, mssl .dnet ! jhp@estgtw.estec.esa.nl, 
sohoswt@solar.stanford.edu, dmuhonen@istp2.gsfc.nasa.gov, 
worrall@istp2 . gsf c . nasa . gov, dmachi@nssdca . gsf c . nasa . gov, 
sohof ot@istp . dnet . estec . esa . nl , kwalyus@gsf email . nasa . gov, 
cbwhite@gsfcmail.nasa.gov, hschweit@istp.dnet.nasa.gov, 
svaghi@estec . esa . nl , cberner@estec . esa . nl , f f elici@estec . esa . nl , 
bandersen@solar.stanford.edu, bochsler@phim.unibe . ch, 
gnoci@solar.stanford.edu, gilbert.leppelmeier@fmi.fi, 
nsp . dnet ! linmpi . dnet ! schwenn@estgtw . estec . esa . nl , 
michels@maple . nrl . navy.mil , ipavich@umdsp.umd . edu, 
wnzel@so . estec . esa . nl , mhuber@estec . esa . nl 
Subject: SOWG meeting 
X- Sun- Charset : US -ASCII 

X-MX- Warning: VMS Mail To: line does not include all To: addresses 
Dear colleagues, 

Please find below our plans for the next meeting of the SOWG. 

Best wishes, 

Vicente Domingo 


From: 
To: 
CC: 
Subj : 


(This information can also be accessed at 

"http : // sohowww . nas com. nasa . gov/ operations /SOWG/ " ) . 

SOHO SOWG meeting 


The next SOWG meeting will take place on 21-24 February 1995 at the 
EOF: 

It will consist of several meetings in series, so that not everybody 
needs to attend the whole meeting. People should come for the day that 
concerns them. 



Tentative break down: 

21 full day and 22 am Participation required: imaging instruments 
specialists 

Software test meeting - Science Planning and scheduling software, and 
command generation software 

The experiment teams will have their software installed 
in the IWS's. The idea is to go room by room having a 
look at the software of the different groups in the 
different topics. This includes the ECS software and a 
check of the exchange of files and information among 
the different tools. The exercise requires the 
participation of the coronal instruments and MDI. The 
other instrument teams are welcome to participate if 
they have an interest in the activity. 

The following topics will be addressed: 

* Science planning software. 

* Pointing tool. We need to address how we're going to use 
ground-based and spacecraft synoptic support data. 

* Instrument data interoperability (data capture and exchange 
from/ to other experimenters) . This was essentially ignored at 
the last sim. 

* Instrument activity plans (IAPs) . At the last sim. , 
questions were brought up about this. We need to better define 
how we're going to use these, and the ECS planning software. 

* Catalog data. We need to define how catalog information will 
be passed from to and from the ECS system. Bill Thompson 
proposes to use a format based on that used for the IAPs. This 
topic about catalog data will be addressed also in the 
following meeting. 


22 pm and 23 am Participation required: Data archive 

specialists 

Data archives and catalogues - including European archives (these may 
require a follow on splinter) 

The following topics will be addressed: 

* Hardware . 

* Catalog data. Keywords and fieldnames. Software available. 

* Information systems: Web server, anonymous- ftp server, 
mailing lists. 

* Mosaic catalog forms. We've made some progress in this area, 
which should be discussed at the meeting. 


* Future developments. 



23 pm and 24 am Participation required: 

PI team Cruise Phase Experts - ESA/NASA PSO - 

MATRA Experts - ESA/NASA Project - FOT 

Early operations timeline 

Issues : 

1. - Planning for Joint Operations (incl. intercalibration and operations 
requiring S/C manoeuvre) 

- Agreement on feasibility and mutually acceptable times 

- check non-interference with non-participating instruments 

- commissioning sheet type write-up per operation 

- S/C activities requiring instrument participation 

2. Planning for intercalibrations after HOI 

3. S/C commissioning after HOI: an overview (informational) 

4. Switch- on screnario: 

- experiments requiring early switch- on (Day 0) for CCD bake out: 
Determination of actions required and feasibility. 

- Feasibility of early SWAN switch- on for lunar observations 

- Timing and order of experiments switch-on; FOT procedures. 

5. Cruise phase operations rehearsals - planning 

6. GSCT2 rehearsal and execution. 


LIST OF UPCOMING ACTIVITIES 


(See "http://sohowww.nascom.nasa.gov/news/" for updates). 

April 24-28 Ground System Compatibility Test 2 (GSCT2) rehearsal 

at GS FC . 


May 1-5 


Second Science Operations Simulation (SIM2) at SOHO 
EOF . 


May 5 


Science Operations Working Group (SOWG) meeting at 
GSFC . 


May 8 
May 9-10 
May 20 -June 2 
July 10-14 


Science Planning Working Group (SPWG) meeting at GSFC. 

Science Working Group (SWT) meeting at GSFC. 

Ground System Compatibility Test 2 (GSCT2) at GSFC. 

Third Science Operations Simulation (SIM3) at SOHO EOF 
(tentative date) . 


V . Domingo 
2 February 1995 



From: MX% "pmartens@esa . nascom. nasa . gov" 17-FEB-1995 20:29:07.88 

To : GALVIN 

CC : MX% "vdomingo@esa . nascom. nasa . gov" 

Subj : Cruise Phase Element of SOWG Meeting 
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Message- ID: <9502180127 . AA04472@lion> 

X-MX-Warning : Warning -- Invalid "To" header. 

To: ; ©distribution (see end of body) 

Subject: Cruise Phase Element of SOWG Meeting 
CC: vdomingo@esa.nascom.nasa.gov 
X -Sun- Charset : US -ASCII 
Content -Length: 23729 


Petrus C. Martens 

SOHO Science Operations Coordinator 

ESA Space Science Division at GSFC 

Tel. : + 1 - 301 - 286 - 9028 

Fax: + 1 - 301 - 286 - 0218 

E-mail : pmart ens@l ion . nascom . nasa . gov 


17 February 1995 

SOHO PI Teams (SOWG + Pis) 

SOHO Project Office 

SOHO Project Scientist Office 

NASA SOHO FOT 

Dear Colleague, 

In preparation of the SOWG on "Cruise Phase Activities" at NASA- GSFC on 
23 and 24 February 1995, I am sending you the following materials: 

1. A list of operational priorities during the cruise phase 

2. Recommendations regarding cleanliness (from Ron Thomas at ESA) 

3. An overview and preliminary timeline of SOHO spacecraft activities 
during the cruise phase based on the MATRA provided SVM commissioning 
sheets . 

4. A summary of the SVM commissioning activities that require 
participation (in most cases pointing verification) from one or more 
experiments . 

5. A list of experiment commissioning activities that involve more than a 
single experiment, or that require S/C maneuvers. 

6. A schedule for cruise phase intercalibration activities proposed by 
the SIWG (prepared by Richard Harrison) 

These materials will also be distributed in print to the participants at the 
meeting. Please forward this message to any of your team members not on the 
distribution list that may be interested or whose input is required. 



are : 

(1) Optics should not be exposed for at least 14 days after launch and where 
they are then sunlit (all but SWAN) , this period should be at least 1 month. 

(2) Where high voltages (>3kV) are used for detectors, these should not be 
powered at all for 14 days and the eventual switch on should allow a slow 
run up to working voltage (3 or 4 steps with 1 hour dwell times for 
example). If the voltages are measured in tens of kV, then wait longer still. 

CDS: 

Initial commissioning day 23, high voltages ON day 46 and doors open day 51 
agrees well with my "rules". 

CELIAS : 

Initial commissioning day 4, high voltages ON day 5 (CTOF & MTOF) , day 13 
(STOF) , MTOF opens covers day 4, STOF day 12 (CTOF open before launch) . It 
is not an optical experiment so opening early may not matter though the time 
between opening and high voltage application needs to be long. Since very 
high voltages are used, my rule 2 is broken and I strongly feel that high 
voltages should not be applied in the first 30 days, with covers open at 
least 20 days beforehand. 

CEPAC: 

Intial commissioning day 5, observations day 8. No doors, no high voltages 
would allow this commissioning sequence. 

EIT: 

CCD heating day 4, internal operation day 7, door fully open day 23. CCD 
heating should be as early as possible, coincident with MDI at +12 hours? 

The internal operation should be deferred to reduce pressure on other early 
operations, but has no special cleanliness constraints, other than to extend 
the CCD heating period. 

GOLF: 

First power at +6 hours, first cell heating at day 4, door open at day 12. 

I would like to see a longer period between heating on and the door opening 
to allow longer outgassing from the hot cell area. I suspect that the first 
two operations are not really necessarily performed so soon and would 
suggest 4, 14 and 30 days respectively as more reasonable unless spacecraft 
operations turn out easy. 

LAS CO: 

First power at day 4, doors open at day 23. No request for CCD heating, 
which is justifiable even earlier, like MDI. Otherwise, OK. 

MDI: 

CCD heating at +12 hours, power on at day 4 (including HR TM if available as 
a spacecraft function then), door open at day 15. I support the CCD heating 
operation, although EIT and CDS have a stronger case than MDI. I regard 15 
days as a little early for the door opening , but the spacecraft TV test may 
help revise that opinion. 

SUMER: 

On at day 7, HV ON at day 56 or 77, door open at day 90. No problem. 

SWAN: 

ON at day 2, science observations at day 3 until 14. The sensors never see 
the Sun after SOHO achieves pointing so there is little contamination risk 
of permanent deposition of organics on the cold mirror surfaces. To expose 
these mirrors within two days of launch seems risky, but the local MLI 
surfaces should be very cold and the mirrors close to room temperature (?) 



From: UMDSP: : GALVIN "Toni Galvin (Univ. Md) " 10-JUL-1995 20:31:37.24 

To : MX% "DIH%MPESMP@MPE . MPE - GARCHING . MPG . DE " 

CC : GALVIN 

Subj : RE: Attending Flight Operation Review at GSFC on 11. /12 . July 95 

Hi Dieter, 

I just got the third copy of your request that I attend the meeting 
tomorrow. In case that means you did not receive my reply - 

I had not planned to attend, but will now do so. 

I suspect that the meeting is not at Goddard, but nearby. 

I will probably be asked about the status of the flight software. Since 
there are known problems with the existing DPU (on the s/c) , at least 
as regards MTOF, I do not know if the s/w is "finished" or not. 


I was out of town for the past two weeks for Solar Wind 8 and IAGA, which 
is why I did not respond sooner. (I was going to take today off to do 
my laundry and mow the grass, but the secretary told me about tomorrow's 
meeting so I came in after all to get your messages.) 


Best regards, Toni 



From: UMDSP: : GALVIN "Toni Galvin (Univ. Md) " 12-JUL-1995 13:44:25.22 

To : PAL : : POLAND 

CC : @MPE , @TUB , GALVIN 

Subj : RE: Information for another review 

Hi Art , 

I tried to get your attention during your presentation this morning, but 
I think you could not see the people in the— back with those bright lights. 
Anyway, if you are -going to be required to submit that viewgragph with 
the "grade report", I have been in touch with the CELIAS PI (Hovestadt, MPE) 
and the CELIAS flight + IWS s/w Co- I (Reiche, TUB) . We came up with a 
consensus, as follows: 


S/W status reply to Art Poland 


(1) 

Flight Software 

A ** 

(2) 

IWS NRT commanding software 

A 

(3) 

IWS load generation software 

N/A 

(4) 

IWS telemetry capture software 

A *** 


A = Finished and ready to go 
B = Acceptable, but needs work 
C = needs work to be acceptable 
N/A = not applicable 

** software patches will probably be needed, can be sent by command. 

*** The EOF- IWS software for commanding and telemetry capture, and some 
basic health of instrument type displays is ready to go. This is a 
PC -based program. 

There will also be a different set of s/w used for the EAF-IWS, which 
will be an AlphaVax program. That software is not as well developed, 
but is more for science -evaluation and has no command or telemetry- 
capture aspects. 


I am sorry for the delay, but I was out of town for the past two weeks, and 
so your request only came to our attention on this past Monday. 

Best regards, Toni Galvin 














From: MX% "vdomingo@so . estec . esa . nl " 14-DEC-1994 11:27:28.33 

To : MX% " gal vin@umdsp . umd . edu " 

CC: 

Subj : SIM1 report 

Return- Path: <vdomingo@so . estec . esa . nl> 

Received: from bcserver.estec.esa.nl by UMDSP.UMD.EDU (MX V4.0-1 VAX) with 
SMTP; Wed, 14 Dec 1994 11:27:17 EST 

Received: from [131.176.17.15] by bcserver.estec.esa.nl (AIX 3.2/UCB 5.64/4.03) 
id AA11683; Wed, 14 Dec 1994 17:28:15 +0100 
From: vdomingo@so.estec.esa.nl 

Received: from lynx by dove.so.estec.esa.nl (5 . 0/SMI-SVR4) id AA29537; Wed, 14 
Dec 94 17:29:45 +0100 

Received: by lynx (5.0) id AA11686; Wed, 14 Dec 1994 17:29:42 --100 
Date: Wed, 14 Dec 1994 17:29:42 --100 
Message- ID : <9412141629 . AA11686@lynx> 

To : galvin@umdsp . umd . edu 
Subject: SIM1 report 
X- Sun- Charset : US -ASCII 
Content -Length: 73901 

Report on the 1st SOHO Science Operations Simulation, held at the EOF 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
on 15-17 November 1994 
%%%%%%%%%%%%%%%%%%%%%% 

V. Domingo, 8 December 1994 

Distribution: SOHO Pi's, PI2s, SOWG, Technical team leaders at SIM1, 

ESA/NASA distribution, Science Ops Evaluation Board 
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1. OVERVIEW 


The objectives and programme of the first SOHO science operations 
simulation were described in the FAX dated 7 October 1994, and updated 
in the e-mail of 7 November, dated 4 November. 

The simulation proceeded as planned. For this first occasion the 
technical operation and the scientific planning were largely decoupled 
to maximize the technical testing. 



This was the first occasion in which all the Instrument Workstations of 
SOHO, the EOF Core System and the Ground System, up to a Spacecraft 
simulator behind the POCC, were put together. Both the PI teams and the 
Ground System staff made a very appreciated effort to run the complete 
system in the most realistic way though when some of the components were 
only partially developed and largely untested. 

The simulation exercise was very successful in showing the strong and 
the weak points in the development status of the science operation, 
i . e . : 


' all the PI IWSs and the ECS were able to receive the telemetry 
and to command the simulated spacecraft, even when all of them 
operated simultaneously. The relatively few noticed discrepancies 
should be easily removed before the next simulation. 

-several of the file transfer functions between the IWS's 
(inter- operability) , and with the ground system (ancillary data 
and summary data) were not tested because they were not available, 
but we intend to have them remotely tested by mid- January. 

- most of the communication functions were successfully tested. 

- the science operations planning by the Science Operations Team 
was exercised in a very preliminary manner, but good enough to 
demonstrate that it is possible to run daily planning meetings in 
reasonably short time, and helped to clarify ideas on how to run 
the planning meetings (see Appendix 2 for collected comments) . 

- the ECS planning tool was run in its preliminary version that 
showed that some refining is needed, now that it is working. Only 
one experiment (CDS) had a planning tool, the others intend to 
build it or to adapt the CDS one. 


- the major shortcoming of the overall science operations appears 

to be the status of the IWS command load generation software that is 
very unequal . 

- the technical facilities (office space, meeting room, 
communications, etc) were proven to be adequate, taking 
into account that the extension rooms of the EOF for early 
operations and auxiliary activities, and the EAF were not yet 
available. The simulation showed how several aspects could be 
improved . 

- the staff that develops and runs the ground segment part (CMS, 
POCC, S/C simulator) were able to test their interface with an 
operating EOF, which helped them and the IWSs operators to find 
mismatches difficult to find otherwise. 

The following chapters contain a descriptive review of the simulation, 
and relevant comments, as seen from the EOF Core System (#2) , a 
summary of the functions that were up for testing and their 
success/failure report (#3) , a listing of the comments that were 
collected at the end of the science planning sessions (#4) , and the 
action plan for the future development of science operations 
preparation (#5) . 



2. REVIEW OF THE TECHNICAL SIMULATION (E. Larduinat) 


2 . 1 Day by day report 


Test 1.1 - File Transfer 

A sample copy of the SOHO Daily report (text files with proper header) was 
transmitted to all the IWSs. This tested the transfer of files from ECS to 
the IWSs. 

The transfer of files from the IWS to the ECS was not formally tested since 
it was to be performed several times during the upcoming days (see transfer 
of delayed command files, input to the activity plan, and summary data 
files) . 


Tests 1.2 - Real-Time Telemetry Distribution For Each IWS Individually 

For each IWS in turn, we established a telemetry session, processed their 
requests indicating which APIDs they want to receive, and transmitted 
telemetry for approximately 5 minutes before terminating the session. 
Telemetry was successfully distributed to each IWS and the APID requests 
corresponded to the requests expected during normal mission operations (see 
table below) . 


Expected APIDs to be distributed to IWS 
CDS 8863, 8 8 A3 , 88A5, 88A6 

CELIAS 8865, 88A9, 8803 

CEPAC 8866, 88AA 

EIT 8869, 886A, 886C, SSAC, 88AF 

GOLF 886F, 88C3 

LASCO 8869, 886A, 886C, 88AC, 88AF, 8803, 8805, 8806, 8809, 8833, 8835, 
8836, 8839, 880A, 8860 
MDI 8893, 8895, 88C5, 80C4 

SUMER ( sumop2 ) 8896, 88C6, 88C9, 8865 

SUMER (sumop3 ) 8896, 88C6, 88C9, 8803, 8860 

SWAN 8899, 88CA, 8860 

UVCS 889A, 88CC 

VIRGO 889C, 88CF 


Tests 1.3 - Real-Time Telemetry Distribution to All IWS Simultaneously 

Test 1.2 was repeated, adding one IWS at a time. We connected to all the 
IWSs and distributed all the requested APIDs for VC0/VC1. Telemetry was 
transmitted for about 1/2 hour to all IWSs simultaneously verifying that the 
ECS can sustain the distribution load. Note that the distribution rate is 
only slightly higher than the incoming PACOR rate due to the fact that very 
few APIDs are requested by more than one IWS at a time. We consider that 
this corresponds to the normal operational conditions since the IWSs do not 
have and do not plan to implement the software to process additional APIDs. 
The only possible future additions are a few Spacecraft house keeping APIDs 
which correspond to a very low additional data rate. 

Connected to MDI workstation to distribute MDI-M data for 20 minutes while 
all other IWSs received the VC0/VC1 data. 

ECS handled the full telemetry distribution load successfully. 



Tests 1.4 - Distribution of Quicklook Files 

Quicklook tape recorder dump files were received from DDF. ECS encountered 
problems with the time stamps, QAC list and missing data unit list in some of 
these files. The problems were corrected by the ECS developers overnight. 
This test was repeated during the following days 


TUESDAY 15 NOVEMBER 1994 (DAY 319) 

Real-Time Telemetry Distribution All IWS Simultaneously 

VC0/VC1 Distribution: Test 1.3 above was to be repeated for the entire day 

(8:00 to 17:00 local) . * 

In the morning, while initiating the telemetry sessions with the IWSs, we 
experienced some difficulties due to the following reasons: 

a) The system was hung writing debugging messages to the 
system console. 

b) The system was hung writing a telemetry message to LASCO 
whose disk was full. After re-starting the telemetry 
distribution software, ECS handled the all -day real-time 
telemetry distribution successfully. 

MDI-M Distribution: In the morning, we received and distributed MDI-M data 

for about 7 minutes. In the afternoon, we connected the with two MDI 
workstations to distribute MDI-M data for about 23 minutes while all other 
IWSs continued to receive the VC0/VC1 data. 

ECS successfully handled the simultaneous distribution of VC0/VC1 and two 
streams of MDI-M data. 

An additional test was attempted: overnight telemetry reception and 
distribution to the IWSs. That test was unsuccessful since PACOR stopped 
transmitting data during the night. This interruption did not cause problems 
with either the ECS or the IWSs. 

Tests 1.4 - Distribution of Quicklook Files 

This test was repeated on November 15. The quicklook data files were 
successfully received from DDF. ECS had corrected the problems encountered 
on November 14. The files were automatically distributed to the IWSs that 
had requested them (GOLF, CDS, SWAN, LASCO, SUMER- sumop2- and MDI) . The 
other instrument groups have elected to retrieve the files from ECS (UVCS 
BIT, CEPAC, CELIAS and SUMER- sumop3 ) . VIRGO has requested to have the files 
automatically forwarded to their home institution in Tenerife. The VIRGO 
quicklook files were successfully transferred even if FTP showed a time-out 
This transfer will have to be re-tested. 

This DDF/Quicklook distribution test was successful. 

Tests 2.1 - Near -Real -Time commanding for each IWS Individually 

All instrument teams are expected to perform NRT commanding, except CEPAC, 
VIRGO, and EIT which will not use that capability. CEPAC will only do 
delayed commanding, EIT will be commanded via LASCO, and VIRGO does not use 
OBDH block commands, which prevent them from commanding from the EOF. 

On Tuesday morning, the following IWSs were individually tested for 
approximately 10 minutes each: 


CELIAS: this IWS had several problems such as command mnemonics in 



lower-case which were rejected by CMS, and missing semicolon at end of 
message. 

MDI : . this IWS also had several problems such as incorrect length in command 
causing arguments to be truncated, and mnemonics in lower-case. 

CDS: this IWS will only command in binary and this was successfully tested. 

SWAN: Successfully tested commanding in both binary and mnemonic formats. 

Also sent an invalid command (empty command) and reset after error was 
satisfactorily tested. 

UVCS : this IWS will only command in binary. Mnemonic commanding was not 

tested. A discrepancy was found with CMS which sent to POCC a rejected 
command. 

GOLF: problem with commands in lower-case. Reset is working properly. 

Binary commanding was not tested this time. 

SUMER- sumop2 : only binary commanding was tested. Mnemonic format will not 

be used. sumop2 could not simulate error to test reset. 

SUMER- sumop3 : Several problems with command format, such as missing 

semicolon. 


On Tuesday afternoon, we continued the individual NRT commanding tests that 
could not be completed during the morning. 

SUMER- sumop3 : problems were corrected by IWS and test was successful. 

Commands in binary format with incorrect length or incorrect checksum were 
accepted by CMS/POCC and uplinked. This is in accordance with the CMS 
requirements, but a DR was generated to document the fact that the instrument 
teams consider these checks to be necessary. 

CELIAS: problems were corrected by IWS and test was successful. 

UVCS: UVCS sent a large number of commands. Several of them failed BARM 

verification and through-put mode was disabled by FOT several times. 

GOLF: successfully tested commanding in binary format. 

MDI -mdisas : several commands in mnemonic format were rejected by CMS 

("syntax error") 

SUMER- sumop2 : successfully tested commanding in binary format. 

MDI -mdisas: successfully tested binary and mnemonic formats 


Simultaneous commanding tests: a CELIAS NRT commanding session was started, 
then, approximately 10 minutes later, UVCS was added. Then LASCO was added 
and the three instruments were commanded simultaneously 


Test 2.1 on 15 November was only partially successful since full simultaneous 
commanding for all IWSs was not tested. 


Background -Queue Files / Large Table Loads 

Large table load files were submitted by MDI and GOLF. They were rejected by 



CMS. The MDI group talked to the CMS developers about the problems. DRs 
were written to document these problems. 


WEDNESDAY 16 NOVEMBER 1994 (DAY 320) 


Real-Time Telemetry Distribution All IWS Simultaneously 

VC0/VC1 Distribution to all IWSs between 8:00 to 17:00 local. 

The telemetry distribution software was initiated to distribute VC0/VC1 data 
to all IWSs. 

Low rate telemetry: The simulator generated 15 minutes of low rate data. 

Several IWSs are interested in processing the Experimenter Housekeeping 
packet (APID 8860) . SUMER and SWAN processed that data and found 
discrepancies with the location of their data within the packet. It was 
identified later as a problem with the compiled ADA code in the SOHO 
simulator which caused a mis -alignment . 

Medium rate telemetry: medium rate VC0/VC1 was received for the rest of the 

day. ECS distributed it successfully to the IWSs, while the ECS operator 
verified the capability to "CANCEL" and "ADD" IWS telemetry sessions during 
the course of a pass. 

MDI-M data: ECS received and transmitted MDI-M data for one hour and fifteen 

minutes to two MDI workstations while transmitting VC0/VC1 data to several 
other IWSs. Towards the end of the session, PACOR sent a big burst of data 
which causes ECS to drop packets to MDI. Also the CAPTURE task terminated 
abnormally. 

The overnight telemetry test failed again due to PACOR problems. 


Distribution of Quicklook Files 

Received the quicklook files from DDF successfully. These files were 
automatically transmitted to the IWSs that requested them. Other IWSs 
retrieved them from ECS. The instrumenters processed these files. UVCS had 
a question concerning fill data in their last packet. It was determined that 
this should be a normal occurrence: fill data will be provided for incomplete 
packets that may occur when the tape recorder was turned off. 

This DDF/Quicklook distribution test was successful. 


Near- Real -Time Commanding for All IWS Simultaneously 

We started the test by providing additional individual time to UVCS, LASCO 
and CELIAS. 

Then simultaneous NRT commanding was tested by adding one IWS at a time: 
GOLF, SUMER- sumop2, SUMER- sumop3 , MDI, CDS, SWAN LASCO, UVCS and CELIAS. We 
experienced several delays with the SMOCC, apparently due to retransmission 
delays of cvommands that failed BARM. 

ECS demonstrated that all the commanding IWSs could be supported 
simultaneously while receiving real-time telemetry. 


Delayed Commanding 



Delayed commands were submitted for uplink on Thursday 17:00 - 18:00. 
Validation reports were received from CMS indicating that the submitted files 
were valid for all instruments except EIT and VIRGO who will not use that 
capability. The submission of delayed command files to ECS and reception by 
CMS was successfully tested. CELIAS send a very large file which caused 
problems in CMS. A DR documented this problem. 


Background Queue Commanding 

Valid background queue files (large instrument table loads) were submitted by 
CDS, LASCO, SUMER- sumop2 , GOLF and UVCS . CMS still could properly validate 
the input from MDI and GOLF. 


THURSDAY 17 NOVEMBER 1994 (DAY 321) 


Real-Time Telemetry Distribution All IWS Simultaneously 

The telemetry system tlm2 stalled twice in the morning which forced us to 
reboot. The reason is not obvious. Interestingly, all the IWSs connected 
with the telemetry subsystem indicated an active socket connection. We need 
to investigate the cause in TCP/IP level. 

VC0/VC1 Distribution to all IWs between 8:00 to 17:00 local. 

Low rate telemetry: The simulator generated 15 minutes of low rate data. 

Medium rate telemetry: medium rate VC0/VC1 was received for the rest of the 

day. 

MDI -M data: ECS received and transmitted MDI-M data for one hour. 


Distribution of Quicklook Files 

Received the quicklook files from DDF successfully. These files were 
automatically transmitted to the IWSs that requested them. This 
DDF/Quicklook distribution test was successful. 

Note: VIRGO instrument telemetry data does not contain LOBT or OBT. This is 

causing a discrepancy with their Archived Telemetry file names and with the 
Quicklook file names. A solution to this problem is being worked on with 
PACOR . 


Near -Real -Time Commanding for All IWS Simultaneously 
Simultaneous NRT commanding was tested during two 2-hour sessions. 


Delayed Commanding 

The delayed command files submitted the previous day were successfully 
uplinked. This was verified by inspection of the Command History Report 
which was only available in hard-copy form. In the future, it should be 
available electronically. 



FRIDAY 18 NOVEMBER 1994 (DAY 321) 


Real-Time Telemetry Distribution All IWS Simultaneously 

15 minutes of low rate. 45 minutes of medium rate 
One hour of NRT commanding 

Reception of Summary data from CDS, EIT, MDI, SUMER and UVCS . 

Input to the Activity Plan from CDS , EIT, LAS CO, MDI, SUMER, UVCS 

Completed testing of ancillary functions such as network time sevices and 
E-mail 



3. TECHNICAL FUNCTIONS. COMPLIANCE MATRIX SUMMARY (L. Sanchez) 


Succ: success 

Part: partially successful 
Fail : failed 
NT: not tested 

TBS: to be supplied ~ 

N/A: not applicable 


3 • l Technical aspects - Matrix by functions 


FUNCTION: NEAR REAL TIME COMMANDING 

NRT Commanding session Succ: UVCS, SWAN, SUMERF, SUMERD, MDI, LASCO, GOLF, 

CELIAS and CDS 
Part : SWAN 

Fail : 

NT : 

TBS: 

N/A: VIRGO, EIT, CEPAC 

- GOLF experimented CMS 'pauses' or 'disables' on Nov 17. 
(Comment: these 'pauses' and 'disables' are 

incuded in the nominal operation of the 
system) . 

Mnemonic commanding Succ: SUMERD, MDI, GOLF and CELIAS 

Part : SWAN 

Fail: 

NT: 

TBS : SUMERF 

N/A: VIRGO, UVCS, LASCO, EIT, CEPAC and CDS 

- PDB format error for SWAN partly overcome by IWS fix. 
(Comment: see response to Schmidt -2 TDR) 

- RCR was enabled for SUMER side on Nov 15 so an error 
flag was always raised: solved reconfiguring SUMER 
after closure of the NRT channel (TDR Buettner-1) . 
(Comment: This was a IWS bad configuration problem) 

- Mnemonics not yet implemented in SUMERF database. 

(No comment) 

CELIAS: Wrong syntax used on Nov 15 (lowercase and no 
semicolon) . Solved on Nov 15 afternoon. 

(Comment: The ICD IWS/ECS will be modified: all 
commands. RPRs and RCRs are uppercase) . 

Mnemonic command status Succ: SUMERD, SWAN, MDI, GOLF, CELIAS 

Part : 

Fail: 

NT: 

TBS : SUMERF 

N/A: VIRGO, UVCS, LASCO, EIT, CEPAC, CDS 

Binary commanding Succ: UVCS, SWAN, SUMERF, SUMERD, MDI, LASCO GOLF 

CELIAS, CDS 

Part : 

Fail: 



NT: 

TBS: 

N/A: VIRGO, EIT, CEPAC 

- UVCS : failed TLOAD, initially. 

- CELIAS did not test during the first two sessions 
(change required in IWS command generation program) . 

Binary command status Succ: UVCS, SWAN, SUMERF, SUMERD, MDI , LASCO, GOLF, 

CELIAS, CDS 

Part : 

Fail : 

NT: 

TBS: 

N/A: VIRGO, EIT, CEPAC 

Rejection by CMS of Succ: UVCS, SWAN, SUMERF, MDI, LASCO, GOLF, CDS 

invalid NRT command Part: SUMERD, CELIAS 

Fail : 

NT: 

TBS: 

N/A: VIRGO, EIT, CEPAC 

- SUMERD, CELIAS: CMS/ECS error messages do not 
dif f erenciate between errors as described in 
the ICD and complementary data sheet 
distributed by the FOT on Nov 16, 1994 (TDRs 
Buettner-2, Galvin- 1) 

(Comment: a Discrepancy Report has been filled to CMS). 

Succ: UVCS, SWAN, SUMERF, MDI, LASCO, GOLF 

Part: SUMERD, CELIAS 

Fail : 

NT : 

TBS: 

N/A: VIRGO, EIT, CEPAC, CDS 

SUMERD, CELIAS: As above (TDRs Buettner-2, Galvin- 1) 

Succ: UVCS, SWAN, SUMERF, SUMERD, MDI, LASCO, GOLF, 

CELIAS, CDS 

Part : 

Fail : 

NT: 

TBS: 

N/A: VIRGO, EIT, CEPAC 

Succ: UVCS, SWAN, SUMERF, SUMERD, MDI, LASCO, GOLF, 

CELIAS, CDS 

Part : 

Fail: 

NT: 

TBS: 

N/A: VIRGO, EIT, CEPAC 

RCR/RPR commanding Succ: UVCS, GOLF 

Part : 

Fail : 

NT: SWAN, SUMERF, SUMERD, MDI, LASCO, CELIAS, CDS 

TBS: 

N/A: VIRGO, EIT, CEPAC 

- A GOLF RPR failed (the procedure was not on FOT list) 


IWS can resume 
commanding after a 
reset 


IWS can send a reset 
to clear the IWS error 
status 


Appropriate response 
received from invalid 
OBDH command rejected 
by ECS 



FUNCTION: NRT THROUGHPUT STATE NOTIFICATION 

Enable/NoRCR Succ: UVCS, SUMERF, SUMERD, MDI, GOLF, CELIAS, CDS 

Part : 

Fail : 

NT: SWAN, LASCO 

TBS: 

N/A: VIRGO, EIT, CEPAC 

Enable/RCR Succ: UVCS, SUMERF, SUMERD, MDI, GOLF, CELIAS, CDS 

Part : 

Fail : 

NT: SWAN, LASCO 

TBS : 

N/A: VIRGO, EIT, CEPAC 

Succ: UVCS, SUMERF, SUMERD, MDI, LASCO, GOLF, CDS 

Part : 

Fail : 

NT: SWAN, CELIAS 

TBS: 

N/A: VIRGO, EIT, CEPAC 

Succ: UVCS, SUMERF, SUMERD, GOLF, CELIAS, CDS 

Part : 

Fail: 

NT: SWAN, MDI, LASCO 

TBS: 

N/A: VIRGO, EIT, CEPAC 

SUMERD: Channel was closed before arrival of 

notification . 

(On Nov 15, p.m. : This was due to a CMS crash) . 

Succ: UVCS, SUMERD, MDI, LASCO, GOLF, CELIAS, CDS 

Part : 

Fail: SUMERF 

NT: SWAN 

TBS: 

N/A: VIRGO, EIT, CEPAC 

SUMERF: Message never arrived or not interpreted. 

(All IWs were receiving this message: IWS software 
problem?) 


FUNCTION: DELAYED COMMANDING 

IWS submits delayed Succ: UVCS, SUMERF, SUMERD, SWAN, MDI, LASCO, CEPAC, 

command file CDS 

Part: GOLF, CELIAS 

Fail: 

NT: 

TBS: 

N/A: VIRGO, EIT 

- GOLF: Accepted by ECS but lost by CMS on Nov 15 & 16 

- CELIAS: Large command file crashes CMS. 

(Comment: The FOT nominal procedures were not 
in place during this simulation, so when a 
crash of the CMS system happened, the operator 
switched to the backup system without 


Paused 


Disable 


Shutdown warning 



recovering the files from the original system: 
these files were lost. This will not happen 
once the FOT procedures are in place) . 

IWS receives command Succ: UVCS, SUMERF, SUMERD, SWAN, MDI , LASCO, GOLF, 

validation report CDS 

Part : 

Fail : CELIAS 

NT: 

TBS: 

N/A: VIRGO, EIT, CEPAC 

- CELIAS: File names as specified in ICD cannot conform 

to PC 8 character limit This caused the truncation of 
validation reports and overwrite of earlier, 
similarly truncated, files. Verification files 
cannot be set to subdirectories because of ' . ' and 
'/' problem: not received. 

(Comment: The validation report files have the 
same filename as the file submitted by the IWS 
with the extension changed to ' .VRP' . So if the 
filename is properly chosen, there will be no 
overwriting. The other option is to download 
the validation reports from ECS via 'ftp', as 
CEPAC does) . 

- CEPAC: retrieves the report with 'ftp'. 

IWS verifies content Succ: UVCS, SUMERF, SUMERD, SWAN, MDI, LASCO, GOLF, 

of command validation CEPAC, CELIAS, CDS 

report Part : 

Fail: 

NT: 

TBS: 

N/A: VIRGO, EIT 

IWS verifies that Succ: 

uplink status is Part: 

properly reflected in Fail: UVCS, SWAN, SUMERF, SUMERD, MDI, LASCO, GOLF 

command history report CEPAC, CELIAS, CDS 

NT: 

TBS: 

N/A: VIRGO, EIT 

- No valid reports were received 

(Comment: This function was not really tested. 

The only report received was in hard-copy 
format) . 

ECS verifies uplink ? 

status (Comment: same as above) . 

FUNCTION: BACKGROUND QUEUE COMMANDING 

IWS submits background Succ: UVCS, SUMERF, CDS 

queue command file Part: 

Fail: MDI, GOLF 

NT: SWAN, SUMERD 

TBS: 

N/A: VIRGO, LASCO, EIT, CEPAC, CELIAS 

- MDI, GOLF: Nominal command files always rejected by CMS 
due to 'block too long', short test files were sent 



successfully. 

(Comment: Two Discrepancy Reports have been 
sent to CMS) 

- SWAN: usually will not use the background queue, 

verified during IWS integration. 

IWS receives command Succ: UVCS, CDS 

validation report Part: 

Fail: MDI , GOLF 

NT: SWAN, SUMERF, SUMERD 

TBS: 

N/A: VIRGO, LASCO, EIT, CEPAC, CELIAS 

IWS verifies content Succ: UVCS 

of command validation Part: 

Fail: MDI, GOLF 

NT: SWAN, SUMERF, SUMERD, CDS 

TBS: 

N/A: VIRGO, LASCO, EIT, CEPAC, CELIAS 

IWS verifies that Succ: 

uplink status is Part: 

properly reflected in Fail: UVCS, SWAN, SUMERF, SUMERD, MDI, GOLF, CDS 

command history report NT: 

TBS: 

N/A: VIRGO, LASCO, EIT, CEPAC, CELIAS 

- No valid reports were received 

ECS verifies uplink ? 

status from CMS - CDS: When ECS crashes the information of the previous 

session is lost after the reboot. 

(Comment: As above, the FOT nominal procedures 
were not in place yet) . 


FUNCTION: TELEMENTRY DISTRIBUTION 

Real-time telemetry Succ: VIRGO ( 1 socket ) 

distribution UVCS ( 2 sockets ) 

SWAN ( 1 socket ) 

SUMERF ( 1 socket ) 

SUMERD ( 1 socket ) 

MDI ( 2 sockets, tipically) 

LASCO ( 1 socket ) 

GOLF ( 3 sockets ) 

EIT ( 1 socket ) 

CEPAC ( 1 socket ) 

CELIAS ( 3 sockets ) 

CDS ( 1 socket ) 

Part : 

Fail : 

NT: 

TBS : 

N/A: 

Real-time distribution Succ: VIRGO ( 2 APIDs , 889c 88cf ) 

of VC0/VC1 packets UVCS ( 2 APIDs , 88cc 889a ) 

SWAN ( 3 APIDs , 8899 88ca 8860 ) 

SUMERF ( 3 APIDs , 8896 88c6 88c9 ) 

SUMERD ( 4 APIDs , 8896 88c6 88c9 8060 ) 



Archived real-time TLM 
retrieval by IWS 


Archive real-time TLM 
sent by ECS 


Archived quicklook TLM 
retrieval by IWS 


MDI 

( 4 

APIDs 

) 





LASCO 

( 6 

APIDs 

) 





GOLF 

( 3 

APIDs 

t 

886f 

88c3 

8860 

) 

EIT 

( 5 

APIDs 

t 

88ac 

8869 

886a 

886c 88af ) 

CEPAC 

( 2 

APIDs 

/ 

8866 

88aa 


CELIAS 

( 4 

APIDs 

/ 

8803 

8860 

8865 

88a9 ) 

CDS 

( 4 

APIDs 

) 





Part : 

Fail : 

NT : 

TBS: 

N/A: 

VIRGO: SC packets include LOBT and VIRGO does not 
incude LOBT (TDR Gomez- 1) 

(Comment: Already fixed). 

VIRGO: SC and HK packets are not time- correlated 
(TDR Gomez- 1) 

(Comment: fixed during the tests). 

SWAN, CELIAS: There was a 12 -byte shift of data (on the 

first 'contact' for SWAN, on the third for CELIAS). 
(Comment: fixed after the problem appeared) . 

SUMER also requested SVM HK 1, 2, 3 and 4 successfully 
MDI: TLM distribution died occasionally. 

(Comment: This is a ECS problem. The ECS team 
is currently looking into that) . 

BIT : One session was terminated by unfamiliar message. 
(Comment: ECS personnel will help EIT to debug this) . 

SUCC : UVCS, LASCO, GOLF, EIT, CEPAC 

Part: VIRGO, CELIAS 

Fail: 

NT: SWAN, SUMERF, SUMERD, MDI, CDS 

TBS: 

N/A: 

VIRGO: The file name convention is based on the LOBT 
and VIRGO SC data does not have LOBT (TDR Gomez- 4) 
(Comment: Pacor is currently looking for 
another naming convention) . 

CELIAS: PC name truncation 

Succ : SWAN, SUMERF, MDI, GOLF, CEPAC, CDS 

Part : VIRGO 

Fail : 

NT: SUMERD, LASCO 

TBS: 

N/A: UVCS, EIT 

VIRGO: Due to restriction in the IWS the files were 
sent to Tenerife, Spain. 

CELIAS: No information. 

Succ: UVCS, GOLF, EIT, CEPAC 

Part: VIRGO, CELIAS 

Fail : 

NT: SWAN, SUMERF, SUMERD, MDI, LASCO, CDS 

TBS: 

N/A: 

VIRGO: The file name convention is based on the LOBT 
and VIRGO SC data does not have LOBT (TDR Gomez- 3) 
(Comment: ECS will adopt the same naming 
convention as Pacor -- see 'Archived real-time 



TLM retrieval by IWS, above) . 

- CELIAS : PC name truncation 

Archive quicklook TLM Succ: SWAN, SUMERF, MDI, GOLF, CDS 

sent by ECS Part: VIRGO 

Fail: 

NT: SUMERD, LASCO, CEPAC 

TBS: 

N/A: UVCS, EIT 

- VIRGO: Due to restriction in the IWS the files were 
sent to Tenerife, Spain. 

- SWAN: HK files sometimes empty. 

(Comment: The problem *may* be solved by now, 
but needs additional testing during the next 
SIM) . 

- GOLF, CELIAS: Header time incorrect. 

(Comment: This was a ECS problem, it is fixed now) . 


FUNCTION: FILE TRANSFER AND SCIENCE SUPPORT DATA EXCHANGES 

Activity plan Succ: UVCS, SWAN, EIT 

Part : MDI 

Fail : 

NT: SUMERF, SUMERD, LASCO, GOLF, CEPAC, CELIAS, CDS 

TBS: 

N/A: VIRGO 

- UVCS: It was unclear which versions of the input files 
were used: should be ordered by start time. 

- MDI: Comment field beyond 80 characters is lost: allows 
only ~10 characters of comments for each program. 
(Comment: This is a ECS problem. Will be fixed 

for the next SIM) . 

- EIT: File name has only 2 digits for year. 

(Comment: The ICD IWS/ECS will be modified to 
include 4 digits) . 

Summary data Succ : 

Part : 

Fail : 

NT: VIRGO, UVCS, SUMERF, SUMERD, MDI, LASCO, GOLF, 

EIT, CEPAC, CELIAS, CDS 
TBS : SWAN 

N/A: 

Predictive orbit data Succ: 

Part : 

Fail : 

NT: ALL 

TBS : 

N/A: 

- Predictive orbit data were not available at ECS. 

Definitive orbit data Succ: 

Part : 

Fail : 

NT: ALL 

TBS: 

N/A: 

- Definitive orbit data were not available at ECS. 


Definitive attitude 


Succ : 

Part : 

Fail : 

NT: ALL 

TBS: 

N/A: 

- Definitive attitude data were not available at ECS. 

Command history report Succ: UVCS, SUMERF 

Part : 

Fail: 

NT: SWAN, SUMERD, MDI, LASCO, GOLF, EIT, CEPAC, 

CELIAS , CDS 

TBS: 

N/A: VIRGO 

Time correlation report Succ: 

Part : 

Fail : 

NT: ALL 

TBS : 

N/A: 

- Time correlation data were not available at ECS. 

SOHO daily report Succ: SUMERF, GOLF, CELIAS 

Part : 

Fail : 

NT: VIRGO, UVCS, SWAN, SUMERD, MDI, LASCO, EIT, 

CEPAC, CDS 

TBS: 

N/A: 

- The only daily report availablw was for Nov 14. 

IWS input to activity Succ: MDI 

Plan Part: 

Fail : 

NT : GOLF 

TBS: UVCS, SWAN, SUMERF, LASCO, EIT, CDS 

N/A: VIRGO, SUMERD, CEPAC, CELIAS 

IWS input to summary Succ: UVCS, SUMERF, MDI, EIT, CDS 

data Part : 

Fail: 

NT: CEPAC, CELIAS 

TBS: VIRGO, SWAN, LASCO 

N/A: SUMERD, GOLF 

- No ARDB information: SUMERF, MDI, EIT 

- CEPAC and CELIAS submit key parameters to CDHF. 

FUNCTION: OTHER EOF FUNCTIONS (communications) 

E ' mail Succ: SWAN, SUMERF, MDI, LASCO, GOLF, EIT CDS 

Part : CELIAS 

Fail: 

NT: UVCS 

TBS: 

N/A: VIRGO, SUMERD, CEPAC 

- At the time of the simulation, there was not possible 



NSI connection 


Time services 


Display of ECS windows 


Informational messages 


to send e-mail outside GSFC. 

(Comment: DNS is fixed now) . 

CELIAS: Their PC cannot send/receive e-mail. Used an 
account at University of Maryland. They request an 
account somewhere in the ECS for this purpose . 

(Comment: Some solution is being worked out 
betweend ECS and Galvin) . 

Succ : VIRGO, SWAN, SUMERF, MDI , LASCO, GOLF, EIT, 

CEPAC, CELIAS, CDS 

Part : 

Fail : 

NT: UVCS 

TBS: 

N/A: SUMERD 

Succ: VIRGO, UVCS, SUMERF, SUMERD, MDI, LASCO, GOLF, 

EIT, CELIAS, CDS 

Part : 

Fail : 

NT: 

TBS : SWAN 

N/A: CEPAC 

CDS discourages the use of broadcasted NTP, as supplied 
by ECS . 

(Comment: Sanchez to find out why) . 

Succ: SWAN, LASCO, GOLF, CELIAS, CDS 

Part: SUMERF, MDI 

Fail: 

NT : UVCS 

TBS : SUMERD 

N/A: VIRGO, CEPAC 

SUMERF: Problems with VMS version of the software. 

MDI: Not reliable. 

(Comment: need some additional information 
about this point) . 

EIT: No information provided 

CELIAS : A verbal request was needed in order to get 
the ECS windows . The PC cannot run the C code provided 
by ECS, so CELIAS requests a Xll -based window 
distribution . 

(Comment: there are problems with 
'little-endian' machines. There are also three 
different workarounds to the problem that can 
be tested during next simulation) . 

Succ: UVCS, SUMERD, GOLF, CDS 

Part : 

Fail: MDI 

NT: SUMERF, CELIAS 

TBS: 

N/A: VIRGO, CEPAC 

MDI: Have not seen any message. 

CELIAS: Phone was used for informational messages. 

No information provided: LASCO, EIT 


FUNCTION: PLANNING AND SCHEDULING 



3.2 Test discrepancy reports 


43 TDR were submitted, 40 different. 

5 - NRT commanding. 

4 - Delayed commanding. 

1 - Background queue. 

1 - Delayed and background commanding. 

2 - NRT telemetry distribution. 

3 - Archived telemetry distribution. 

7 - File transfers and science support data exchanges. 
16 - Other EOF functions 
1 - Planning and scheduling. 

3 - SUMER 


Blum 1 
Buettner 2 
Charra 2 
Galvin 2 
Gomez 5 
Gurman 1 
Larduinat 1 
Martens 10 
Payne 6 
Platzer 2 
Sanchez 6 
Schmidt 2 
Thompson 3 


NRT COMMANDING 


SCHMIDT 
DESC : 
REASON: 
RECOV: 

COMM: 


RESP: 


-1: FAILED. NRT commanding of SWAN TC NBLLOCKN 
Command was rejected as critical command. 

'Critical' flag set in PDB . 

Flag should be removed in the MATRA- supplied database by MATRA/ESA. 
Verification on POCC side that sending of this command is allowed. 
It is essential that the command can be sent directly from the 
IWS during initial commissioning. The effects of this command 
on the instrument are guarded by instrument hardware and fliqht 
software. 

This TDR is issued to ensure to keep the issue open until it is 
resolved. 

The FOT will prepare a procedure to request modifications in 
he database contents. This is the procedure that should be used 
in this case. 


SCHMIDT-2: FAILED. NRT telecommanding of some SWAN TCs 

DESC: 15 out of 65 SWAN commands were rejected by CMS due to syntax 

error. 1 

REASON: PDB contains only partial masks for some parameter constants 
due to wrong format in PDB. 


RECOV: 1) SWAN- IWS implemented workaround solution: subsequent test 

were sucessful. 

2) PDB has to be corrected after last MATRA supplied database 
is implemented. 

It is important that the final database is checked by SWAN team 


COMM: 



members as early as possible. 

RESP: This will be fixed by FOT in the conversion process of the PDB. 

SWAN should test it again during next simulation. 

BUETTNER- 2 : PARTIALLY SUCCESSFUL. Rejection of commands / appropriate 
response by CMS/ECS. 


DESC: 

CMS/ECS error messages do not differentiate between errors as 


described in ICD and complementary 
Nov 16 , 1994 . 

sheet distributed by 

FOT on 

REASON: 

Not implemented 



RECOV: 

? 



RESP: 

A Discrepancy Report has been sent 

to CMS . 


GALVIN- 

1 : PARTIALLY SUCCESSFUL. Appropriate 

responses to invalid commands. 

DESC: 

Several different kinds of invalid 
'reason codes' were reasonable. 

commands were tried. 

Not all 

REASON: 

Ask CMS! 



RECOV: 

To implement ICD table 3.4 

EXPECTED 

RECEIVED 

COMM: 

INVALID COMMAND TYPE 

ERROR CODE 

ERROR CODE 


Start CMD request not received 

10 

10 


Syntax error 

2 

2 


Mnemonic not found in PDB 

3 * 

2 * 


Duplicate ID 

5 

5 


Disabled by previous error 

11 

11 


Binary disallowed 

6 

6 


Invalid instr. for this socket 

9 * 

2 * 


Critical command 

7 * 

2 * 


Wrong number of parameters ( 1 ) 

? * 

2 * 


Throughput shutdown 
* - Error 

1 

1 


(1) - I am not sure if this counts as format error or syntax error. 
RESP: A Discrepancy Report has been sent to CMS. 

PAYNE- 4 : PARTIALLY SUCCESSFUL. RCR, RPR. 

DESC: RCRs and RPRs were only tested with dummy files. 

COMM: FOT required to provide STOL. CDS supply FOT with list of new RCRs. 

RESP: This function should be retested during the next simulation, 

once the RPR and RCR are at FOT. 

DELAYED COMMANDS 


LARDUINAT- 1 : UNSPECIFIED. Delayed commands. 

DESC: Delayed command files rejected by CMS. 

RECOV: Do not put embedded blanks in 'ORIG_ID' field of file. 

RESP: The ICD between IWS/ECS will me modified accordingly. 

GALVIN- 2 : FAILED. Delayed commands. 

DESC: Delayed commands do not allow for 'Pause' or 'Wait' in between 

commands . 

RECOV: Include capability of 'wait xx min' or 'wait xx sec' into 

delayed command file. 

COMM: Use of multiple delay files to compensate for lack of 'wait' 

capabilities did not work. Use of 'dummy' commands (i.e. real 
commands with no function) required large command lists (-1200 
lines) wich crashed CMS. 

RESP: It appears that there is no way to achieve this. In any case, 

Eliane Larduinat will clarify this topic with CMS. 



From: UMDSP: : GALVIN "Toni Galvin (Univ. Md) " 31- JAN- 1995 23:15*18 4 7 

To: IPAVICH 

CC : GALVIN 

Subj : eof hw status as of SIM1 

Hi Fred, 

The following is my report on the EOF. Give everyone my best. 

Toni 

The current H/W at the SOHO EOF consists of a PC- clone 486 provided 
by TUB. The software is similar to that used for s/c tests, and provides 
basic snapshot capabilities for the dpu and sensors. (Each sensor team 
is responsible for making up their respective displays.) The system 
is excellent for sending commands, but the current set up has the 
following limitations: 

(1) There are no internal checks on command validity or command 
safety (i.e., critical commands) . One can place passwords 
on command buttons, but there are many ways to circumvent 
that. Also, right now existing command buttons are in 
binary, which we have decided as a team never to use. 

(Binary commands are not checked by the FOT database.) 

(2) The PC needs additional hard disk storage space. 

(3) The PC does not have the necessary h/w and s/w to 
receive or send e-mail messages. This hindered 
communication with the Flight Operations Team, and 
the Science Operations Coordinator. As a temporary- 
solution, we had the mail sent to UMD. But this 
requires looking at the account --an urgent 
message would not be seen for hours/days. Even 

if the ALPHA VAX in the EAF has mailing 
capabilities, the EAF is physically in a different 
building from the EOF and hence has the same 
limitations as an account at UMD (or UB, or MPE, 
or MPAe or TUB) . 

(4) The SOC will send quicklook, realtime retrieved 
telemetry, and other ancilliary data 

files directly to defined destinations. But, the 
file names are too long for the PC, and the 
truncation keeps the least significant information. 

Since the PC only keeps the latest version of the 
files that end up with the same name, we ended up 
having the files sent to the IMP/Vogager disk at 
UMD --a temporary solution at best. This may 
be solved with the use of the ALPHA VAX at the 
EAF. 

(5) The GSE program can only read telemetry in realtime. 

It cannot read the telemetry files mentioned in 
point (4) . That means the GSE can only look at 
data that was recorded on its own system. This 
data must be requested manually through the GSE 

and must be restarted manually in the event of 
a telemetry dropout (which occurred fairly 
frequently as the FOT went down) . It was not 



clear at the time if the s/w being developed 
by Peter Wurz would work on the FOT recorded 
data files (he has copied some of these files 
from the UMD IMP/Voyager account to UB for tests) . 
Even if the Bern s/w works -- there is not as yet 
HK displays available. Again, this s/w 
would require the use of the EAF VAX. 

(6) It is still assumed that each sensor will bring 
its own PC and printer to the EOF. MPE will 
supply the ALPHA VAX and x- window monitor to 
the EAF. UMD will supply a laser jet printer 
to the EAF. UB will supply the s/w to the 
EAF. 

(7) The PC environment had difficulty with the 
x-window ECS (EOF Command System) displays 
(written in C on a Unix system) , so we had 
to by-pass the normal procedures. We have 
to ask for the ECS window displays to be 
distributed to us as a passive client. 

This seemed to work ok, but there is 

no guarantees that it will always be 
available. The displays contain information 
on command processing and telemetry availability, 
and is therefore most useful in the EOF, not the 
EAF (where the ALPHA VAX would have the 
capabilities) . 

Another note, not hardware related: 

CELIAS, as a non-resident IWS, is expected to use 
DELAYED commanding. The capabilities and limitations 
of this form of commanding was never discussed or 
documented before this SIM. The setup for DELAYED 
commanding was apparently written under the assumption 
that each experiment was capable of internal time 
tagging for command execution. (Apparently this capability 
is true for most SOHO experiments.) As such these 
command files are only appropriate for single commands 
or groups of commands where no "pauses" between 
commands are needed, and where the time of execution 
is not critical. Also, delayed commands are completely 
automated: All comments you insert are stripped out 

by the computer before the FOT gets the file. So don't 
expect any manual checks or intervention by the FOT. 

Our best bet seems to be to use pre-written FOT procedures. 
This means having these procedures ready months or at least 
weeks ahead of time. The FOT hope to eventually get 
procedures done within a few days of 
submission, but that capability is not yet proven. 

The FOT estimated that the procedures that they received 
last October would be ready by March or April . While I 
am sure this will speed up with practice, it will also slow 
down as more teams submit procedures. (The procedures have 
to be translated to TSOL and tested before use.) 

I think each sensor team will have to be responsible for 
writing their own procedures, although I can interact with 
the FOT on implementation. It would be useful for all 



teams to have a DPU manual on the available commands and 
associated parameter definitions. I know I could use one. 



From: MX% "vdomingo@so . estec . esa . nl " 20-JUN-1995 11:31:35.58 

To: MX%"sohoswt@solar. Stanford. edu" ,MX%"cdp@astrol.bnsc. rl .ac .uk" ,MX%"galvin 

CC: 

Subj : SOHO SIM3, SWT15 and other meetings 

Return- Path: <vdomingo@so . estec . esa . nl> 

Received: from dove (dove.so.estec.esa.nl) by UMDSP.UMD.EDU (MX V4.0-1 VAX) 
with SMTP; Tue, 20 Jun 1995 11:31:30 EDT 
Received: from lynx by dove with SMTP id AA0&901 (5 . 67b+/IDA- 1 . 5 ) ; Tue, 20 Jun 
1995 17 : 32+10 +0200 

Received: by lynx id AA01384 ( 5 . 67b+/lDA- 1 . 5 ) ; Tue, 20 Jun 1995 17:31:41 +0200 
Date: Tue, 20 Jun 1995 17:31:41 +0200 
From: Vicente <vdomingo@so . estec . esa . nl> 

Message- ID: <199506201531 . AA01384@lynx> 

To: sohoswt@solar.stanford.edu, cdp@astrol.bnsc.rl.ac.uk, 

galvin@umdsp.umd.edu, if kki . dnet !mueller_m@estgtw. estec . esa . nl , 

gurman@uvsp . gs f c . nasa . gov , lumme@sara . cc . utu . f i , grec@ayalga .unice.fr, 

howard@maple . nrl . navy.mil , rbush@solar.stanford.edu, 

plemaire@solar . Stanford . edu, Walter . Schmidt@fmi . f i , 

vanballe@cfa.harvard.edu, ajm@iac.es, poland@pal.gsfc.nasa.gov, 

cst@sdac . gsf c . nasa . gov, bf leck@so . estec . esa . nl , 

pmartens@so . estec . esa . nl , lsanchez@so . estec . esa.nl , 

elarduinat@ess -mail . atsc . allied . com, vdomingo@so . estec . esa . nl , 

mssl . dnet ! j hp@es tgtw . estec . esa . nl , bandersen@solar . Stanford . edu , 

bochsler@phim.unibe . ch, gnoci@solar.stanford.edu, 

gilbert . leppelmeier@fmi . f i , 

nsp.dnet ! linmpi . dnet ! schwenn@estgtw.estec.esa.nl, 
mi chel s@mapl e . nr 1 . navy .mil, ipavi ch@umdsp . umd . edu , 
dmuhonen@istp2 .gsfc.nasa.gov, worrall@istp2 .gsfc.nasa.gov, 

Dino.Machi@ccmail . gsf c . nasa . gov, kwalyus@gsf email . nasa . gov, 
wwagner@leda . hq . nasa . gov, Ken. Sizemore@ccmail .gsf c . nasa . gov, 
svaghi@estec . esa . nl , cbwhite@gsf email . nasa . gov, cberner@estec . esa . nl , 
f f elici@estec . esa . nl , f vandenb@estec . esa . nl , 
kwenzel@estcsl . dnet . estec . esa . nl , mhuber@estec . esa . nl 
Subject: SOHO SIM3, SWT15 and other meetings 
X-Sun-Charset : US-ASCII 

X-MX-Warning: VMS Mail To: line does not include all To: addresses 

To SOHO Pis, members of SOWG 
copy PI2s, ESA/NASA distribution 

Subject: 3rd Science Operations simulation, 15th SOHO SWT, other 
meetings 

Dear Colleagues, 

The following is to help plan your activities in the near future, and 
to try to avoid misunderstandings about dates. 


1. SIM3 

The 3rd SIM will take place on the 7-11 August 1995 

At this time most of the operations system will be in its final form, 
the EAF will be fully functional , the relatively short list of 
disfunctions that have occurred during SIM2 will have been corrected. 
The Instrument Work- stations (IWS) will have gone through two 
simulations and one Ground System Compatibility test and should be able 
to demonstrate full functionality. For IWSs of the NRT commanded 



instruments we should expect that an educated but not necessarily 
expert should be able to execute the following procedures. 

a) Develop a unique observing sequence for a scientific objective (i.e. 
make a raster image in several spectral lines, make an image in a 
selected area in the field of view) . 

b) Put several observing sequences into a group to form a study (i.e. 
images of bright points, images of prominences, etc) 

c) Put several observing sequences together to make a daily plan. 

d) Generate a complete set of commands and send them to the ECS. 

e) Generate a daily plan to be put into the SOHO daily plan. 

f) Generate a detailed as planned log that can be used to see what the 
instrument should be doing at what time. 

g) Generate an as -run log that can be used to see what was actually 
observed. 

h) We will play back data from GSCT2 . Show that the IWS can capture, 
display, and put data into FITS files. 

During the next three weeks we will put together a complete plan for 
the SIM3 . Pleases comment and give suggestions. I would assume that the 
Science Planning/Science Operations Team will meet on Monday 7 August. 

2. Science Working Team meeting (SWT 15) 

I suggest that we hold it on the afternoons of the Wednesday and 
Thursday (9-10 August) during SIM3 (most of the Pis agree with this 
proposal) . On Wednesday we would start with a review of the status of 
the instruments, by then delivered - what Phil calls an experiment 
readiness review, so that everybody knows how the other instruments are 
ready to perform. On Thursday we would concentrate on the spacecraft 
and mission. An item prominent in the agenda must be early operations - 
including commissioning. If short of time we can expand on Friday, or 
use the Thursday morning for splinter meetings. 

3. As a reminder, the Flight Operations Review (FOR) will take place on 
11-12 July at Marriott Hotel, 6400 Ivy lane, Greenbelt, Md. 

4. On 13 July morning, following the FOR meting, we like to have a 
meeting of the Public Relations Working Group, to which all Pi's are 
invited and encouraged to attend. The aim is to discuss and agree the 
ESA and NASA plans for public relations activities, particularly after 
launch. We will come back to you with more details and an agenda in the 
near future. 

Please, let me know your ideas and points that you like to be included 
in the agenda of the different meetings 

Best wishes, 

Vicente Domingo 



From: MX%"vdomingo@so . estec . esa . nl " 12-JUL-1995 22:50:51.58 

To: MX%"sohoswt@solar . stanford.edu" ,MX%"cdp@astrol.bnsc. rl .ac.uk" ,MX%"galvin 

Subj : SOHO science operations simulations 

Return- Path : <vdomingo@so .estec . esa . nl > 

Received: from dove (dove.so.estec.esa.nl) by UMDSP.UMD.EDU (MX V4.0-1 VAX) 
with SMTP; Wed, 12 Jul 1995 22:50:48 EDT 
Received: from lynx by dove with SMTP id AA18998 (5 . 67b+/IDA- 1 . 5 for 
<galvin@umdsp.umd.edu>) ; Thu, 13 Jul 1995 04:46:51 +0200 
Received: by lynx id AA06144 (5 . 67b+/IDA- 1 . 5 ) ; Thu, 13 Jul 1995 04:46:42 +0200 

Date: Thu, 13 Jul 1995 04:46:42 +0200 
From: Vicente <vdomingo@so . estec . esa . nl> 

Message -ID: <199507130246 . AA06144@lynx> 

To: sohoswt@solar.stanford.edu, cdp@astrol.bnsc.rl.ac.uk, 

galvin@umdsp . umd . edu, if kki . dnet !mueller_m@estgtw. estec . esa . nl , 

gurman@uvsp . gsf c . nasa . gov, lumme@sara . cc . utu . f i , grec@ayalga . unice . f r , 

howard@maple.nrl.navy.mil, rbush@solar.stanford.edu, 

plemaire@solar . Stanford . edu , Walter . Schmidt@fmi . f i , 

vanballe@cfa.harvard.edu, ajm@iac.es, poland@pal.gsfc.nasa.gov, 

cst@sdac . gsf c . nasa . gov, bf leck@so . estec . esa . nl , 

pmartens@so . estec . esa . nl , lsanchez@so . estec . esa . nl , 

elarduinat@ess -mail .atsc.allied.com, vdomingo@so . estec . esa . nl , 

mssl . dnet ! j hp@es tgtw . estec . esa . nl , 19 709. dnet ! JLC@estgtw . estec . esa . nl , 

dmuhonen@istp2 .gsfc.nasa.gov, worrall@istp2 .gsf c .nasa . gov, 

Dino .Machi@c email . gsf c . nasa . gov, sohof ot@istp . dnet . estec . esa . nl , 
kwalyus@gsf email . nasa . gov, hschweit@istp . dnet .nasa.gov, 
svaghi@estec . esa . nl , cberner@estec . esa . nl , f f elici@estec . esa . nl , 
mhuber@estec . esa . nl , kwenzel@estcsl . dnet . estec . esa . nl , 
jmariska@solar . Stanford . edu 
Subject: SOHO science operations simulations 
X- Sun -Charset: US-ASCII 

X-MX-Warning: VMS Mail To: line does not include all To: addresses 

To SOHO Principal Investigators and to members of the Science Operations Team 
cc: ESA/NASA 

Subject: SOHO science operations simulations and end to end tests 
Dear Colleague, 

This is to you of the upcoming activities related to science operations 
including some updates . 

2nd science operations simulation (SIM2) 


We have sent by mail copies of the report on the 2nd simulation. They 
include reports by 1) SIM2 Evaluation Board, 2) GSFC Code 303, Systems 
Assurance Management, 3) Project Scientists Team. 

3rd science operations simulation (SIM3) 


You can find the schedule for the week and supporting information in 
the SOHO World Web pages under "SOHO Science Operations simulation 3". 
I attach a copy of them for completeness. 


New information is: 



From: MX%"pmartens@lion. nascom.nasa.gov" 3-JAN-1995 17:15:37.00 

To : GALVIN 

CC : . MX% " vdomingo@l ion . nascom. nasa .gov" , MX% " cst@sdac . gsf c . nasa . gov" , MX% " lsanc 

Subj : Second Ground System Compatibility Test 

Return- Path : <pmartens@lion . nascom. nasa . gov> 

Received: from east.gsfc.nasa.gov by UMDSP.UMD.EDU (MX V4.0-1 VAX) with SMTP; 
Tue, 03 Jan 1995 17:15:35 EST 

Received: by east.gsfc.nasa.gov (5 . 57/Ultrix3-: 0-C) id AA08617; Tue, 3 Jan 95 
17:11:32 -0-500 

Received: by lion (5 . 0/SMI-SVR4) id AA16867; Tue, 3 Jan 1995 17:11:05 -0500 
Date: Tue, 3 Jan 1995 17:11:05 -0500 

From: pmartens@lion.nascom.nasa.gov (Petrus C Martens) 

Message- ID: <9501032211 . AA16867@lion> 

To : cbwhite@gsf email . nasa . gov, elarduinat@ess -mail . atsc . allied . com, 
vanballe@cf a . harvard . edu , waiter . schmidt@f mi . f i , 
payne@solg2 . bnsc . rl . ac . uk, rock@quake . Stanford. edu, 
charra@iaslab.ias.fr, galvin@umdsp.umd.edu, lemaire@iaslab.ias.fr 
Subject: Second Ground System Compatibility Test 
CC: vdomingo@lion.nascom.nasa.gov, cst@sdac.gsfc.nasa.gov, 
lsanchez@lion . nascom. nasa . gov, poland@pal . gsf c . nasa . gov, 
kwalyus@gsfcmail.nasa.gov 
X- Sun- Charset : US-ASCII 
Content -Length: 1484 

Dear Colleague, 

A second ground system compatibility test (GSCT2 ) has been tentatively 
scheduled for 18-28 april 1995. This test will involve -- for the first time 
-- ALL experiments in an end-to-end test. The exact date has not yet been 
determined, but the April timeframe is a safe guess. 

For scheduling of this test we need to have a first guess from you 
how much time you would like to have for NRT commanding of your instrument. 

Please note that this is NRT commanding only - - the FOT time needed to run 
their/your TSTOL Procedures is already accounted for. It is important to have 
your estimates for time requirements a.s.a.p., to impress upon the project 
the necessity of allowing for sufficient time, in an early phase of the 
preparations. 

According to Chris StCyr it is quite likely that the ESA Project will 
require a test script from each of you detailing what commands will be sent 
from the EOF, so you should consider that as part of your planning. 

I will be looking forward to your early reply, so that the schedule can 
be discussed in more detail at the upcoming SWT. 

Please note that this message is sent by Piet Martens, and not, as 
you were used to, by Chris StCyr -- I will be gradually taking over Chris's 
jobs, as Chris will start as a member of the LASCO team. I hope I will be 
able to do as good a job as Chris has done over the last couple of years. 

THANK YOU CHRIS! 

Yours sincerely, 


Piet Martens 



From: SDAC::CST "CHRIS ST. CYR/ATSC/SOHO/682/GSFC (301-286-2941)" 

To: UMDSP: : GALVIN 

CC: 

Subj : Proposed schedule for GSCT#2 rehearsal 

TO : SOWG 

FROM: C. St.Cyr and C. Cazeau 

DATE: 09 March 1995 

RE: PI team rehearsals for GSCT#2 

Attached is our proposed schedule for the rehearsal activities prior 
to Ground System Compatibility Test #2 (GSCT#2) , which is 
scheduled to begin 20 May. 

Each PI team should plan to spend at least two days working with 

the FOT member (listed below) who has been assigned to their instrument. 

The activities will include review of the script and the TSTOL Procedures, 
and execution of those Procedures against the spacecraft Simulator. 

We will also want to exercise any near- realtime commanding scripts 
from the EOF during this rehearsal. 

We believe that two days will be sufficient for each team, but we have 
left Friday open as a contingency day. If this schedule is not suitable 
for your team, please inform us immediately and we will try to 
accomodate change requests. 

Since they are located near GSFC, the LASCO/EIT team have agreed to hold 
their rehearsal during the week of 17-21 April. We believe that GOLF and 
SWAN may require only one day since they participated in GSCT#lb. 

MDI also participated in GSCT#lb, but the TSTOL Procedures for that 
instrument are quite extensive. 

Mon Tue Wed Thu Fri 

(24 Apr) (25 Apr) (26 Apr) (27 Apr) (28 Apr) 

GOLF 
SWAN 
CELIAS 
VIRGO - 


MDI > CEPAC > 



CDS 

> 

> 

SUMER 

> 

> 

UVCS 

> 


Flight Operations Team Instrument Assignments 

LASCO/EIT - Chad Quach 
GOLF - Mark Hill 
SWAN - Chad Quach 
CELIAS - Brett Sapper 
VIRGO - Bud Benefield 
MDI - Roger Rowe 
CDS - Mark Hill 
SUMER - Travis Bailey 
UVCS - Brett Sapper 
CEPAC - Tom La Fave 


13 -M 



"Toni Galvin (Univ. Md) " 13-APR-1995 19:33:27.37 


From : UMDSP : : GALVIN 

To : @SOWG 

CC : GALVIN 

Subj : gsct#2 and SIM2 

TO CELIAS SOWG DISTRIBUTION, 

The following are in answer to specific messages from Peter 
Wurz and Fredi Buergi, but are of interest to everyone. 

Toni 


Hi Peter, 

I asked Chris StCyr about the socket availability for the upcoming tests. 
The Mission Planning Room (aka "overflow area" aka Conference room near 
the EOF) will be wired and ready for CELIAS, CEPAC, VIRGO, GOLF, and 
additional SWAN gear. They plan to have it ready for the rehearsal week 
for GSCT#2 . (Rehearsals are the week of 24 April, and precede the SIM2) . 

So whatever we would have available for launch, we will have next month. 

They are also getting the kitchen in shape. 

Art Poland told me he is busy putting a "plan" together for the SIM2. 

The main emphasis (currently, anyway) is on daily science planning 
for the coronal instruments. StCyr says that they hope to keep the ground 
system functional testing (i.e., our sending commands and/or getting 
telemetry) to a minimum. So I think the two of us should be able to 
more than handle SIM2, as it is not clear there will be much for non- 
resident experiments to do. I guess the SOWG is still that Friday morning. 

bye, 

Toni 

>From: MX% "WURZ@phim. unibe . ch" 13 -APR- 1995 02:29:54.13 

>To : MX% "BOCHSLER@phim. unibe . ch" , MX% "galvin@iimdsp.umd. edu" 

>CC: MX% "WURZ@phim. unibe . ch" 

>Subj : 

>Dear Toni, 

>To update your head count, I want to inform you that I shall come for the 
>week of SIM 2 tests. I will arrive on Saturday and stay for a week. Fredi 
>told me that he will be there the week before and somebody else too, so I 
>think there is enough CELIAS staff for the GSCT#2 rehearsal. 

Concerning connections I would think that we would need our four Ethernet 
>sockets again. I am planning to bring a lap top (to use as a terminal) , and 
>1 guess so do you. Including the EGSE we will use already three sockets and 
>if somebody else comes with a computer there is only one socket left. 

>Best regards, 

>Peter 


Hi Fredi, 





OK, there seems to be some confusion here. 

IWS commanding: Commanding via the IWS is for near realtime, or else is 

a request for commanding by the FOT . For IWS NRT commanding we just send 
our commands by typing them in to the command mode of the IWS. This is 
one command at a time and is what we tested in last year's SIM. (Note, do 
not expect the pre-existing GSE command buttons to work "as is" -- Thomas 
Hauck, Peter Wurz, and I tried that at last November's SIM1. There is a 
format change that is required, also right now all the existing buttons 
correspond to a binary command structure, and as a team we decided at the 
Portsmouth Co-I meeting "no binary commands will be used for safety reasons". 
(We should probably test the option of binary, even if we never plan to use 
it.) It is good to script this out, as I think any procedures should be 
written down first, with the expected response, but the NRT script is for 
our own use as far as I know. However, I am sure that the FOT would like 
to know what to expect . 

FOT commanding. If we have pre-existing procedures that we would like the 
Flight Operations Team to send for us, then they will take our "plain 

language” script and THEY will make it into a STOL procedure. You and I 

9 ave the FOT an edited version of the "OBS" procedure to work with last 

fall, and Brett Sapper of the FOT has been translating it into STOL. 

I also gave him some procedures to write up for turning On and Off the 
DPU for main and redundant (this makes up 4 procedures!), just so they 
can do that before/after we do any real-time IWS commanding. I had 
hoped to do more FOT procedures, but it is unclear what we want them to 
do versus what we plan to do for ourselves with near- realtime commands. 

FOT STOL procedures are not implemented by us, but are requested by 
us for implementation by the FOT. The FOT then fits the request into 
their available timeline for sending commands. If I understand the set-up 
correctly, after launch (not testing) this will often be at the start of 
the "work day" before resident experiments take over with the real-time 
commanding from their IWS's. 

I have received a copy of the CELIAS GSCT#2 package from Brett Sapper. It 
arrived late last week, while I was out of the office (Ulysses SWT in Kiel, 
then some other out -of -of f ice activities) , so frankly, I only found it in my 
mail pile today. I will have Cassie FedEx you the 30 odd pages tomorrow, 
as I assume you will not be working Easter weekend anyway. I will also 
have a copy FedEx' d to Reiche. 

The script for the GSCT#2 includes 

(1) Submit (for later execution by FOT) delayed commanding for CELIAS. 

(2) Power on CELIAS 

(3) Run the FOT procedure for OBS mode 

(4) Exercise CELIAS NRT commanding (from the IWS) . I do not 
know how much time we will be allotted for this activity - 
i.e., how many commands we will be sending, but this is 
where we, the experimeter, directly command 
from the CELIAS workstation (IWS) during our time slot. 

For MTOF , we want to execute the new auto- calibration 
sequence, and Fred Ipavich has promised that he and Bedini will 
talk to me about it soon. However, we may need Reiche' s 
input on the actual MTOF commands . 

Submit (for execution by FOT) a Remote Command Request, RCR, 
for CELIAS. An RCR is a request to the FOT to execute a 
"predefined command sequence" or PCS. Definition and approval 
of PCS's are directly coordinated between the FOT and the 
experimenter. We have never tested, nor written, one of 


( 5 ) 



these, so this should be fun. 

(6) Submit (for execution by the FOT) a Remote Procedure Request, 

RPR, for CELIAS. An RPR is a request to the FOT to execute 
a FOT-approved pre-existing STOL procedure. Since we only 
have the OBS procedure available (other than turning ON/OFF 
the DPU procedures), I suppose we will re-submit the OBS. 

(7) Submit Large Instrument Table Load for CELIAS through a Background 

Queue request. I do not think CELIAS has table loads (in the 
sense meant by this command option) , at least that is what I 
gathered _ from earlier conversations with Hauck and Reiche about 
this option. (This item obviously has "ask Reiche" written 
all over it.) 

(8) Disable near realtime commanding for CELIAS. 

(9) Power off CELIAS STOL procedure is run by the FOT. 

(10) Power on CELIAS STOL procedure is run by the FOT for the 

redundant side 

(11) FOT executes OBS STOL procedure. 

(12) Power off CELIAS STOL procedure for redundant side, run 

by FOT . 

THE END. 

Toni 


P.S. you could not reach me by phone, because I actually got up early 
to go to NASA HQ. 


P.S2. There should be people around on the 26th to discuss WIND, but if 
you want Gloeckler specifically, let us know, as he oftens works 
at home and may not be planning to come in per se. Paquette, the 
science programmer will be in. Let me know who else would you want 
to talk with (i.e., Doug Hamilton for MASS, or Fred Ipavich for SWICS, 
or me for STICS) , or the type of discussion, and I will try to 
round people up. 


>From: MX% "buergi@mpe-garching.mpg.de" 13 -APR- 1995 06:14:06.16 

>To: MX%"galvin@umdsp.umd. edu" 

>CC : MX% "reiche@ida . ing . tu-bs . de" , MX% "gruenwaldt%linmpi@mpe .mpe-garching .mpq . 

>Subj : SOHO GSCT-2 rehearsal 

>Dear Toni 

>1 have tried to call you on the phone, but you were not there. 

>My current ideas about the GSCT are the following: 

>We want to carry out a full SFT (maybe excluding the boring bit with the 
>many combinations of sensors in verify) PLUS some additional tests with the 
>commands that overwrite the classification tables. 

>1 will try to set up a script for this, since I already have the SFT on my 
>PC, but I have no idea whatsoever what the TSTOL format should look like. 

>Could you enlighten me? 

>As far as I know, the following people will attend the GSCT-2 rehearsal 
>with CELIAS on 24.-25. April: 

>Bornemann, Buergi, Galvin and Reiche. 

>There will be nobody from CTOF. Peter Wurz will come for the SIM- 2 in the 



>following week, but not the GSCT rehearsal. 

>Walter Bornemann and myself plan to arrive on Fri. 21. and leave on Wed. 26. 
>We will stay at the Greenbelt Holiday Inn. 

>Please let me know before Wed. 19. if these plans conflict with the Goddard 
>schedule . 

>With best regards 

>Fredi 

>PS. 

>1 would like to come to UMd to discuss WIND matters on Wed. 26. if that is 
>possible. Will anybody be there? 

>PS2 . 

>MPE will be closed over Easter until Tue. 18. 



From: UMDSP: : GALVIN "Toni Galvin (Univ. Md) " 20-APR-1995 18:24:41.71 

To : ECD1 : : LINMPI : : LINAX1 : : GRUENWALDT 

CC: @SOWG, GALVIN 

Subj : RE: dress rehearsal for GSCT2 coming up 24-25 April 

Dear CELIAS SOWG colleagues, 

I received a request from Heiner Gruenwaldt about upcoming 
flight operations tests for SOHO. Since this is of general interest, 

I am replying to all. 

The calender information on upcoming SOHO events is available 
through the World Wide Web Homepage for SOHO, which has the URL 
address of 

http://sohowww.nascom.nasa.gov/ 

If you then go to the "meetings" subsection, there is a lot of s/c and 
flight operations calender information. 

Remembering that all dates are tentative, the following is a synopsis of 
the flight ops tests: 

April 24-25 : the CELIAS rehearsal for the upcoming GSCT#2, where 

we will meet with our CELIAS -FOT contact to straighten 
out any FOT displays, procedures, etc problems. 

May 1-5 : SIM2, the Second Science Operations Simulation, which 

may not have much to do with CELIAS, as I have bee 
n told that it will emphasize coronal instrument daily 
planning. But I have not received an agenda yet. 

May 20 - June 2: Ground System Compatibility Test #2, in which we 

will send real commands to a real s/c. 

July 10-14 : SIM3 . This includes testing out the EAF facilities. 

I have no specific information on this test, but 
some experimenters have recommended that instead of 
working on daily planning sessions for the coronal 
instruments, we may want a dry run for instrument 
commissioning. I assume the purpose of SIM3 will 
be discussed at the May 5th SOWG. 

From July to August the s/c gets packed up and sent to the Cape. 

Aug 28- Sept 9 : s/c SFT at KSC. This is not a Flight ops test, 

but I thought you would be interested. 

Sept 17-19: : GSCT #3 . I do not have specifics, but this 

should again be real commands to a real s/c. 

Oct 4-6 : End to end testing. 


All dates are of course subject to change. 


best regards , 


Toni 



From: UMDSP: : GALVIN "Toni Galvin (Univ. Md) 

To : @SOWG 

CC: BEDINI,LASLEY, GALVIN 

Subj : upcoming GSCT2 tests for Celias 

TO: Fredi Buergi 

CC: Dieter Hovestadt 

Lead Co- Is 

Dear Fredi, 


10-JUN-1995 17:19:26.79 


I received your fax on the script for this coming week. 

On Tuesday, we performed the STOF table load command file, using a 
one second delay. It took about three trys. It eventually worked after the 
FOT inserted a 3 second delay (on their end, not ours) . I understand that 
they think this has to do with the phone connection in Toulouse. 


On Wednesday, I went to Goddard and spoke to Brett Sapper and 
Carline Cazeau about the script proposed in your fax. Carline agreed 
in principle to the use of the redundant side for one day or other of 
the testing, and said she would negociate this matter with Matra. 

In today's meeting (Saturday), this request was confirmed -- on 
Monday we will try out the FOT procedures for ON and OFF on the 
CELIAS redundant side. 


I also left Carline the proposed scenario for the ESR test (for 
next Wednesday) . She again agrees in principle, but again needs to get 
MATRA consent. This is because Matra will do the actual set up of the 
experiments before the ESR test - the FOT are not planning on sending the 
sensor commands from here at Goddard. I think we will get it - at least 
so far everyone has been very cooperative. 

I have submitted Delayed command files for both Monday and 
Tuesday. Just the FBDUMMY commands. 

I will use the Verify modes for the Monday tests. 

I can manually (i.e., by typing in the commands myself) do the 
Diagnostic procedures on Tuesday. Because this is an NRT Commanding 
test, not a Remote Procedure Request test, my use of RPR will be 
very limited. I have spoken to Carline and Eliane Larduinat, and 
a couple of the FOT members about the use of RPRs. I am told I can 
do this, but only if the entire procedure takes less than 3 minutes. 

I do not think any of our procedures are that short - they were designed 
for safety, not speed. (Maybe you can check with the command log how 
long they took last week.) The reason we cannot use long procedures 
during the NRTCommanding test is simple - whenever a procedure is 
run by the FOT, the NRT Commanding is disabled until the procedure is 
finished. Since this is a combined NRT commanding period for all 
experiment groups, we cannot monopolize the link. 

I do not see any problem with my running the commands manually, 
but since the CTOF procedure contains High Voltage -related commands, and 
the STOF procedure contains bias commands, I just want the Lead Co- Is to 
be aware of what I will be doing. 

Best regards, 


Toni 



From: UMDSP: : GALVIN "Toni Galvin (Univ. Md) " 13-JUN-1995 16:09:28.45 

To : @SOWG 

CC : GALVIN 

Subj : celias activities for 13 June95 gsct#2 

To: Fredi Buergi and Dieter Hovestadt 

CC: CELIAS Lead Co- Is (SOWG distribution list) 

Date: 13 June 1995 

The DPU HK showed a parity error sometime between 0656 and 0917 
GMT (based on what printouts are handy from when sensors were all 
OFF to all in SB) . A second parity error is seen on a printout for 
the MTOF verify mode at 0932 GMT. 


First NRT session on 13 June 1995 

13 June95 0858 GMT 

0907 

0908 

0928 

0933 

0940 

1032 

1033 

1038 

1039 


FBMMOD1I 

MTOF 

standby 

FBSMOD1I 

STOF 

standby 

FBCMOD1I 

CTOF 

standby 

FBMM0D3 I 

MTOF 

verify 

FBSMOD3I 

STOF 

verify 

FBCM0D3I 

CTOF 

verify 

FBMMOD1I 

MTOF 

standby 

FBMM0D4 

MTOF 

autocal 

FBSMOD1I 

STOF 

standby 

FBCMOD1I 

CTOF 

standby 


At the time that the command went in for mtof autocal, the dpu 
idle time went to almost zero, and stayed there for a few minutes 
before returning to nominal values. The dpu seemed to be recalculating 
tables or something. I assume that is normal? 

Second NRT session: 


13June95 

1211 

FBMMOD1I 

MTOF standby 


1215 

1216 

FBSMOD2 I 

verify stof in standby 
STOF manual 


1218 

FBSLIMBI , 0x0 AD2 

set SSD bias limit 
to 210, delta to 10. 



this command uplinked successfully, 
but the STOF limits screen showed 



SSD Bias limit 

= 80, delta = 10 


1223 

resent above command 



SSD Bias limit 

= 210 delta = 10 


1226 

FBSENASB 

SSD bias enabled 


1228 

FBSSBON 

SSD bias on 


1230 

FBSSBV, OxOOCA 

Set bias volt step 202 
SSD Bias volt = -91.55 


1234 

FBSM0D4 

STOF autocal 


with the command that I had trouble with, I confirmed that I had sent 
it correctly. Perhaps it takes some time to implement? If it only 



starts on a science record, I may not have waited long enough. 

Data link dropped out at 13:33 GMT, one hour into the STOF autocal . 
Data link re-established at 14:14 GMT. 

13 June95 1429 FBCCTRL, 0x0021 set HVPS red/off, 

WPS off (CTOF) 

1433 FBCENA enable HV (CTOF) 

1436 FBCLIMHV, 0x0000 set HVPS limit 

(HVPS limit = 0, 
delta = 0) 

1439 FBCHVPS , 0x0007 set hvps stp 7 

1442 FBCM0D4 Ctof autocal 

Data link lost at 14:39 GMT. Decided to start turning things 
to standby/off since no visibility. 

1451 FBMMOD0I MTOF off 

1457 FBSM0D1I STOF standby 

Telemetry regained, but other teams claimed that 
they were getting partial packets. 

1526 FBCMOD1I CTOF standby 

1527 FBSMOD0I STOF off 

1530 FBCMOD0I CTOF off 

NRT link closed at 1545. 

Warm turn on 1623 GMT. Switch to low bit rate. Received OBT 
at about 1745 GMT. Later returned to normal (medium) bit rate. 

Delayed command file (3xFBDUMMY) sent at 1900 GMT. Cmd cnt 
incremented by 3 . 

Experiment turn off by Matra 1939 GMT. 

Tomorrow is the ESR test. 


Toni 



From: UMDSP: : GALVIN "Toni Galvin (Univ. Md) " 14-JUN-1995 06:26-43 96 

To : @SOWG 

CC : GALVIN 

Subj : celias esr test results. Note MPE and ECD1 nodes are down. 

To: Fredi Buergi and Dieter Hovestadt 

CC: CELIAS Lead Co- Is (SOWG distribution list) 

Date: 14 June 1995 


MATRA turn on procedure CLS_0N was begun at 14 June95 0550. 


14 June95 


(mistake 


0552 

0558 

0559 
0559 

in data base has 


CELIAS ON 

Celias turned on in one try, MPB 1 
OBT command 
FBPERM, 0x0301 

FBCESRON esr = standby 

power off /standby esr commands switched) 


Note: the default (turn on) value for ESR message was "Power OFF". 
This later changed to "Standby" . I am pretty sure the command 
counter incremented by two at the time of the change in ESR status 
(not at the time the commands were sent) . Is that delay appropriate? 

The Matra telemetry data base has ESR messages messed up. They 
interpret raw value of 0x0001 as STANDBY, and 0x0002 as "POWER 
OFF". My copy of the Digital Status Defn Table (TUB IDA 25/04/95 
version 5.2) says the opposite (FDDESRD: 0 = disabled, 1 = power off 

2 = standby) . 


Yesterday, the ESR message never changed from "Power OFF" status. 
This may indicate a problem. Yesterday, I had seen the command 
counter increment by two some few minutes after the initial turn 
on. (That is to say, that the command OK counter was = 1 after the 
OBT, then later it changed to = 3) . Since earlier, someone had come 
around from the FOT saying that the some experiments would be 
getting the OBT again, I had assumed that was the reason for the 
command counter. After I received the inquiry yesterday from 
Matra regarding the ESR message status, I asked the Matra 
representative here at GSFC whether or not the new CLS_ON had 
been used, which includes the time tag FBPERM, 0x0301 and ESR 
response FBCESRON, and he thought not. Now I am questioning that, 
as the command count increment by 2 today would match the two 
commands. IF THE COMMANDS WERE SENT YESTERDAY, then the DPU 
received them but did not implement them. The major difference 
that I see between yesterday and today is that the DPU required 
two power-ons yesterday and ended up in MPB 2 (today it is in MPB 1) . 


NRT session on 14 June 1995 to configure for ESR test. 

14 June95 0726 GMT FBCMOD1I CTOF standby 

0730 FBMMOD1I MTOF standby 

0741 FBCM0D3I CTOF verify 

Sometime at or after the MTOF to standby command, the parity 
error count went to 1. To see whether or not this was 
coincident with the MTOF mode change, the following commands 
were sent . 



0750 GMT 

0751 


FBMMOD3 I 
FBMMOD1I 


MTOF verify 
MTOF standby 


As soon as the MTOF verify command went through, the parity 
error count went to 2. Returning to standby did not affect 
the error count (i.e., it stayed at 2) . 


14June95 1002 GMT ESR sent - loss of telemetry 

When the low bit rate telemetry became available, the CELIAS 
status was not as expected. 


Command OK Counter incremented by one. 
ESR MESSAGE still reads Standby. 

STOF POWER OFF 
MTOF POWER OFF 
CTOF POWER OFF 


> That's GOOD. 

> Unchanged. 

> Unchanged. 

> Should be Standby! 

> Should be Standby! 


The PDU display showe a current of 0.077, consistent with 
only having the DPU on. 


Either the FBCESRON command really is the Power Off command and 
the ESR Message status is WRONG in the GSE display (FM 5.06) , or 
the DPU does not function as advertized. Is is currently 1022 GMT, 
so unless the DPU takes longer than 20 minutes to activate Stan db y 
mode, this is it. 


Toni 


The DPU will remain on for until 3 pm local time (1900 GMT) , when 
all experiments will be turned off by Matra. Then there will be 
a debriefing meeting at 4:30 pm (1.5 hours to get ready for it) . 



"Toni Galvin (Univ. Md) " 14-JUN-1995 17:24:30.31 


From: UMDSP: : GALVIN 

To : @SOWG 

CC : GALVIN 

Subj : end of gsct#2 

To: Fredi Buergi and Dieter Hovestadt 

CC: CELIAS Lead Co-Is (SOWG distribution list) 

Date: 14 June 1995 

The CELIAS off procedure was performed by Matra at 1932 GMT. 

This is the end of GSCT#2 . 

I have explained to the Matra representative about the mixups 
in the GSE vs. data base values for the ESR mnemonics. The Matra 
representative has asked that a new fax be sent to them explaining 
the ESR data base problems, since the fax sent yesterday by Fredi 
to Gardelle and Bories said just the opposite, but has now been 
found to be inconsistent with our observations. This is to prevent 
Matra from changing the data base in response to the first fax. 

Fredi - maybe you can handle this when you get to Matra, or 
you can send an updated fax? 

I think it would be very useful if Kay updated the data 
base lists and sent me a copy. I know that in addition to 
the ESR problems, there is also an STOF command that needs 
to have the number of data words changed. Also Peter Bedini 
has some changes to make to the conversion curves for some of 
the MTOF data, and this has to be submitted to MATRA. 

I can cross-check the Goddard version 7 data base when it 
comes out, but not if the data base I have has errors. 

I also explained how the DPU may have failed to implement 
the same ESR command yesterday that worked today. I asked to 
get a copy of the MATRA control file for yesterday so that we 
can see if the time delay command was sent too late for 
an implementation in the first set of science records, vs. having 
to wait 21 hours for implementation. If that turns out to be 
the case, perhaps a longer time delay would be appropriate. 

Even today, with no multiple DPU starts required, it took 9 minutes 
from the DPU turn on until Matra sent the FBPERM command. If the 
current time clock only allows for a 15 minute window, I can see 
where multiple DPU turn ons could easily make one miss it. This 
was reported by Matra as an anomaly, so I guess a formal response 
may be needed to close it. 

Fredi - thanks for writing the CELIAS test summary report. 

Another note: NASA now requires home addresses for accreditation 

purposes. The following CELIAS people need to send this information 
to Jean Desselle at GSFC, fax 301-286-0218. 

BERN: Aellig, Balsiger, Bochsler, Fischer, Hefti, 

Kallenbach, Wurz 

MPAE : Gruenwaldt , Winterhoff, Goll, Clette, Esser 

This is for access into GSFC (not the KSC list, which is 
separate) . Fredi sent out a fax about it several months ago. 

Jean does not have any names for MPE or TUB, which I think is 
odd --if you think you are coming to GSFC for the CELIAS 



commissioning, I suggest you may have to re-submit the 
information. 

Bye, 


Toni 



From: MX% "cst@sdac . gsf c . nasa . gov" 23-MAY-1995 17:49:13.53 

To : MX% "bpotter@gsf email . nasa . gov" , MX% " rmenrad@gsf email . nasa . gov" , MX% " j welch 

Subj : GSCT#2 

Return- Path: <cst@sdac . gsf c . nasa . gov> 

Received: from SDAC (sdac.gsfc.nasa.gov) by UMDSP.UMD.EDU (MX V4.0-1 VAX) with 
SMTP; Tue, 23 May 1995 17:49:11 EDT 
Date: Tue, 23 May 1995 17:45:25 -0400 - 

Message - ID: <9505231-7452589@sdac.gsfc.nasa.gov> 

From: cst@sdac.gsfc.nasa.gov (CHRIS ST . CYR/ATSC/SOHO/682 /GSFC 
(301-286-2941) ) 

To: bpotter@gsfcmail.nasa.gov, rmenrad@gsfcmail.nasa.gov, 

jwelch@gsf email . nasa.gov, jmckim@bigsim.atsc.allied.com, 
vdomingo@soho . estec . esa . nl , lsanchez@soho . estec . esa . nl , 
bf leck@soho . estec .esa.nl , pmartens@lion.nascom.nasa.gov, 
kim@ecsman . nascom. nasa . gov, whitec@thorin . atsc . allied . com, 
cazeauc@th.orin . atsc . allied . com, elarduinat@ess - mail . atsc . allied . com, 
rock@quake.stanford.edu, scott@quake.stanford.edu, 

CHEVALIER@sag . space . lockheed . com, waiter . schmidt@fmi . f i , 
michel . berthe@aerov .jussieu.fr, curdt@l inaxl . dnet . gwdg . de , 
howard@maple.nrl.navy.mil, scott@argus.nrl.navy.mil, 
wang@cedar . nrl . navy.mil , eit@xanado . nascom. nasa . gov, 
muel 1 er - mel 1 in@kernphy s ik . uni -kiel .d400.de, lumme@sara . utu . f i , 
galvin@umdsp . umd . edu , wur z@phim . unibe . ch , buergi@mpe - gar ching . mpg . de , 
petrou@sapvxg . saclay . cea . f r , cf rohlich@ezrzl . vmsmail . ethz . ch, 
fgr@ll.iac.es, jhl@iac.es, harrison@solg2.bnsc.rl.ac.uk, 
payne@solg2 . bnsc .rl.ac.uk, cdp@as t rol . bnsc . rl.ac.uk, 
macwan@orpheus . nascom. nasa . gov, lwang@orpheus . nascom. nasa . qov 
S ubject: GSCT#2 
X - VMS - To : @SOWG 

X-MX-Warning: VMS Mail To: line does not include all To: addresses 

TO : SOWG 

FROM: C. St.Cyr 

DATE: 23 May 1995 

Here are a few thoughts about the upcoming GSCT#2 activities, from an 
EOF perspective. I have not taken time to structure them, so please 
feel free to ask questions. 


As of this writing, here is my (UNOFFICIAL!) schedule: 


29 

May 

(Mon) 

Day 

0 

FOT orientation for ESA and Matra 

30 

May 

(Tue) 

Day 

1 

AOCS (36 hours continuous) 

31 

May 

(Wed) 

Day 

2 

AOCS , VIRGO 

01 

Jun 

(Thu) 

Day 

3 

LASCO/EIT, SWAN 

02 

Jun 

(Fri) 

Day 

4 

DHSS/COBS, CELIAS 

03 

Jun 

(Sat) 

Day 

5 

CEPAC, Thermal 

04 

Jun 

(Sun) 



No testing 

05 

Jun 

(Mon) 



No testing 

06 

Jun 

(Tue) 

Day 

6 

CDS 

07 

Jun 

(Wed) 

Day 

7 

CDS 

08 

Jun 

(Thu) 

Day 

8 

MDI 

09 

Jun 

(Fri) 

Day 

9 

MDI , SUMER 

10 

Jun 

(Sat) 

Day 

10 

AOCS, GOLF 

11 

Jun 

(Sun) 



No testing 

12 

Jun 

(Mon) 

Day 

11 

DHSS/COBS, 1.6-hour pass, IIDE, ECS verification 

13 

Jun 

(Tue) 

Day 

12 

8 -hour pass, simultaneous NRT 

14 

Jun 

(Wed) 

Day 

13 

AOCS, ESR 



As you are aware, the GSCT#2 activities take place during Toulouse 
business hours. The test is scheduled for 11 hours each day, with an 
additional hour available for contingency. The daily schedule is: 

(All times Local GSFC) 

01:00 Pre-test briefing and configuration check 
02:00 Testing activities begin 

09:00 Status briefing during FOT shift hand-over 

14:00 Testing activities end 

15:30 End of day briefing; replanning for next day 

To support the experiment teams in the EOF we will operate in two shifts. 

From 01:00-09:00, Bill Potter and I will be available to operate the ECS 
and to assist the experiment teams. From 08:30-16:00 Eliane Larduinat, 

Piet Martens, and Luis Sanchez will staff the SOC office. The ECS developers 
and System/Network Administrators will be available on-call. 

Based on the experience of GSCT#1 and GSCT#lb, the 15:30 end-of-day 
briefing is the most important. That is where any replanning of future 
activities occurs. 

Other EOF residents will also be available to help the PI teams. These 
people include Dominic Zarro, Liyun Wang, Bill Thompson, Donald Luttermoser, 
and Snehavadan Macwan. 

On another topic, each PI team should pick up a copy of the latest 
Flight Operations Plan from the FOT secretary (Donna Hammer) . 

Also of interest, each PI team should plan to meet with the Simulator 
development team during their visit to Goddard. John Welch and John McKim 
are the two people who you need to meet with, and Eliane or I can 
coordinate the arrangements for those meetings. 

-- end of rambling -- 



From: MX% "cst@sdac . gsf c . nasa . gov" 31-MAY-1995 02:00:45.70 

To : MX% "vdomingo@soho . estec . esa . nl " , MX% "lsanchez@soho . es tec . esa . nl " , MX% "bf le 

CC: 

Subj : GSCT#2 Day 1 Summary 

Return- Path: <cst@sdac . gsf c . nasa . gov> 

Received: from SDAC (sdac.gsfc.nasa.gov) by UMDSP.UMD.EDU (MX V4.0-1 VAX) with 
SMTP; Wed, 31 May 1995 02:00:43 EDT 
Date: Wed, 31 May 1995 01:54:51 -0400 
Message- ID: <95053 101545163@sdac . gsf c . nasa . gov> 

From: cst@sdac.gsfc.nasa.gov (CHRIS ST. CYR/ATSC/SOHO/682 /GSFC 
(301-286-2941)) 

To: vdomingo@soho.estec.esa.nl, lsanchez@soho.estec.esa.nl, 
bf leck@soho . estec . esa . nl , pmartens@lion . nascom. nasa . gov, 
kim@ecsman . nascom. nasa . gov, elarduinat@ess -mail . atsc . allied . com, 
rock@quake . stanford.edu, scott@quake . stanford.edu, 
waiter . schmidt@fmi . f i , curdt@linaxl . dnet . gwdg . de , 
howard@maple . nrl . navy.mil , scott@argus . nrl . navy.mil , 
wang@cedar . nrl . navy.mil , eit@xanado . nascom.nasa.gov, 
mueller-mellin@kernphysik.uni-kiel.d400.de, lumme@sara.utu.fi, 
galvin@umdsp . umd . edu , wur z@phim . unibe . ch , buergi@mpe - gar ching . mpg . de , 
petrou@sapvxg . saclay . cea . f r , cf rohlich@ezrzl . vmsmail . ethz . ch, 
f gr@ll . iac . es , harrison@solg2 .bnsc . rl . ac . uk, payne@solg2 .bnsc . rl . ac . uk, 
macwan@orpheus . nascom. nasa . gov, lwang@orpheus . nascom. nasa . gov, 
lutter@orpheus . nascom. nasa . gov 
Subject: GSCT#2 Day 1 Summary 
X- VMS -To: ©SUMMARY 

X-MX- Warning : VMS Mail To: line does not include all To: addresses 

From: SMTP%"/l=D/G=KEITH/S=WALYUS/O=GSFCMAIL/PRMD=GSFC/ADMD=TELEMAIL/C=US/@x40 

To : /DD . UN=SOHOSIT/0=GSFCMAIL/PRMD=GSFC/ADMD=TELEMAIL/C=US/@x400 . gsf c . nasa . q 

CC: 

Subj : GSCT-2 Summary for Test Day 1 

GSCT-2 Summary for Test Day 1 (May 30) 

- FOT testing began at 03:40 (local), which was one hour and forty 
minutes later than planned. The start of the test was delayed by the 
failure of the SCOE (spacecraft operational environment) , which is 
located at Toulouse, France. MMS personnel are examining the 
problem and are not yet able to state when the SCOE will be ready, 
although it will not be earlier than Thursday (June 1) . The FOT tested 
for 8.5 hours on day 1. 

- The original test script planned for testing the L&EO scenario and 
other AOCS activities for 48 continuous hours beginning on Monday 
morning and completing on Wednesday morning. Since these activities 
require the use of the SCOE, they will be postponed until later in the 
test . 

In place of the L&EO and AOCS activities, the FOT substituted 
activities which did not require the SCOE. These activities included: 

ACU memory write and compare; thermal activities, not including the 
reconfiguration recovery; and two of the five polarity checks. 

- Mondays test day completed at 14:00. With the postponement of 
the L&EO and AOCS activities, the 48 hour test will be postponed to a 
later date during the test. Because of the SCOE failure, MMS engineers 
have stated that 3 extra test hours may be available per day if required 
by the FOT. The Project has stated that the FOT will use the extra time 



if available, but MMS must notify the Project by the mid- shift briefing 
on the previous day to allow the FOT time to schedule their personnel . 

Test scenarios for the remainder of the week are still very fluid due to 
the uncertainty of the SCOE, and the uncertainty as to whether the Pis 
b e available earlier for testing their instruments than previously 
planned. 

TENTATIVE PLANS FOR TEST DAYS 2-4 

Wednesday: The FOT will test the VIRGO and LASCO instruments. 

To complete testing on the two instruments, the FOT will require 13.5 
hours of test time. MMS will check tomorrow to see if the extra 2.5 
hours of test time can be allocated. If the extra time can not be 
allocated, LASCO will not be fully tested, and the FOT will have to re- 
do some of the LASCO testing in addition to completing the remaining 
LASCO segments. MMS personnel will know by 03:00 (local) if the 
extension is possible. 

Thursday: The FOT will test SWAN, and CELIAS or CDS. 

Additionally the FOT will assist MMS in trouble-shooting of the 
SCOE. 

Friday: If the SCOE is ready, the FOT will test the L&EO scenario for 

36 hours, and finish the 12 -hour AOCS activities the following week. 

If the SCOE is not working, the FOT will continue testing CDS and 
CELIAS. MMS has proposed moving the start of day fours activities 
up four hours to 22:00 on Thursday to provide extra margin for testing 
the L&EO sequance if the SCOE is ready. NASA Project has the 
action to determine if NASA can support an earlier start time. 

================== RFC 822 Headers ================== 

X4 00 -Received: by mta wheelo.gsfc.nasa.gov in /PRMD=NASA/ADMD=TELEMAIL/C=US / ; 

Relayed; Tue, 30 May 1995 16:22:33 -0400 
X4 00 -Received: by / PRMD=gs f c/ ADMD= telemail /C=us / ; Relayed; 

Tue, 30 May 1995 16:16:00 -0400 
Date: Tue, 30 May 1995 16:16:00 -0400 

X400 -Originator: /l=D/G=KEITH/S=WALYUS/0=GSFCMAIL/PRMD=GSFC/ADMD=TELEMAIL/C=US/@ 
X400-Recipients : non-disclosure:; 

X4 00 -MTS -Identifier: [/PRMD=gsfc/ADMD=telemail/C=us/;ZJJF- 1827 -3039/15] 

X4 00 -Content -Type: P2-1984 (2) 

From: /l=D/G=KEITH/S=WALYUS/0=GSFCMAIL/PRMD=GSFC/ADMD=TELEMAIL/C=US/@x400 . gsf c . n 
Message-ID: <ZJJF- 1827 - 3039/l5*@MHS> 

To : /DD . UN=SOHOSIT/0=GSFCMAIL/PRMD=GSFC/ADMD=TELEMAIL/C=US /@x400 . gsf c . nasa . gov, 
cst@sdac . gsf c . nasa . gov, Robert_0' Brien@ccmail . gsf c . nasa . gov, 

Ralph . Vi ehman@c email . gsf c . nasa . gov, Michael . Richter@gsf c . nasa . gov, 
/DD.UN=DPERKINS/0=GSFCMAIL/PRMD=GSFC/ADMD=TELEMAIL/C=US/@x400 .gsfc.nasa.gov, 
/DD.UN=VOXENHAM/O=GSFCMAIL/PRMD=GSFC/ADMD=TELEMAIL/C=US/@x400. gsfc.nasa.gov, 
/DD . UN= JBRUNER/ 0=GS FCMAIL/ PRMD=GS FC/ ADMD= TELEMAIL/ C=US / @x4 0 0 . gsf c . nasa . gov 
Subject: GSCT-2 Summary for Test Day 1 



MX%" cst@sdac.gsfc.nasa.gov" l-JUN-1995 01:30:16.04 

MX% "vdomingo@soho . estec . esa . nl " , MX% " lsanchez@soho . estec . esa . nl " , MX% "bf le 
Day 2 summary 


From: 

To : 

CC: 

Subj : 

Return- Path: <cst@sdac . gsf c . nasa . gov> 

Received: from SDAC (sdac.gsfc.nasa.gov) by UMDSP.UMD.EDU (MX V4.0-1 VAX) with 
SMTP; Thu, 01 Jun 1995 01:30:13 EDT 
Date: Thu, 1 Jun 1995 01:10:18 -0400 
Message- ID : <9 50601011018 6 l@sdac . gsf c . nasa . gov> 

From: cst@sdac.gsfc.nasa.gov (CHRIS ST. CYR/ATSC/SOHO/682/GSFC 
(301-286-2941)) 

To: vdomingo@soho.estec.esa.nl, lsanchez@soho.estec.esa.nl, 
bf leck@soho . estec . esa . nl , pmartens@lion. nascom. nasa . gov, 
kim@ecsman . nascom. nasa . gov, elarduinat@ess -mail . atsc . allied . com, 
rock@quake . Stanford. edu, scott@quake . Stanford. edu, 
waiter . schmidt@f mi . f i , curdt@l inaxl . dne t . gwdg . de , 
howard@mapl e . nrl . navy.mil , scott@argus . nrl . navy.mil , 
wang@cedar . nrl . navy.mil , eit@xanado . nascom. nasa . gov, 
mueller-mellin@kernphysik.uni-kiel.d400.de, lumme@sara.utu.fi, 
galvin@umdsp . umd . edu , wur z@phim . unibe . ch, buergi@mpe - garching . mpg . de , 
petrou@sapvxg.saclay.cea.fr, cfrohlich@ezrzl.vmsmail.ethz . ch, 
f gr@ll . iac . es , harrison@solg2 . bnsc .rl.ac.uk, payne@solg2 . bnsc .rl.ac.uk, 
macwan@orpheus . nascom. nasa . gov, lwang@orpheus . nascom . nasa . gov, 
lutter@orpheus.nascom.nasa.gov 
Subject: Day 2 summary 
X- VMS -To : @ [CST. SOHO. GSCT2] SUMMARY 

X-MX-Warning: VMS Mail To: line does not include all To: addresses 

From: SMTP%"/l=D/G=KEITH/S=WALYUS/0=GSFCMAIL/PRMD=GSFC/ADMD=TELEMAIL/C=US/@x40 

To : /DD . UN=S0H0SIT/0=GSFCMAIL/PRMD=GSFC/ADMD=TELEMAIL/C=US /@x4 00 . gsf c . nasa . g 

Subj: GSCT-2 Summary for Test Day 2 (May 31) 

GSCT-2 Summary for Test Day 2 (May 31) 

F0T testing began at 02:08 (local), and completed at 14:08. The 
testing was extended two hours to accommodate LASC0 testing. 

During LASC0 testing, an anomaly occurred when a large instrument 
table load was rejected by the spacecraft. The signature of this error is 
similar to errors witnessed during GSCT-1 and GSCT-1B. The F0T 
and MMS engineers are analyzing the problem, and will devote two 
hours of spacecraft time tomorrow to further study the problem. It is 
anticipated that this problem may occur again during the test. 

The F0T will support MMS engineers in analyzing the SC0E 
problem on Thursday. MMS engineers estimate that this support will 
require one hour of test time. Although the SC0E is not yet working, 
the test team has replanned the agenda such that the SC0E will not be 
required until next week, which will allow MMS engineers more time to 
correct the problems without adversely affecting the simulation. 

The tentative schedule through June 10 is listed below. Except for 
six hours of A0CS testing and two hours of testing a warm start-up, all 
activities have been accounted for in the schedule. Days 11-13 (June 
12-14) have not changed from the original baseline schedule. All days 
have the nominal 11 hour schedule unless otherwise noted. 

Tentative Schedule of Test Days 3-10 (May 31- June 10) 



Test Day 3 (May 31) (13.5 hours) 

Thermal reconfiguration 

- SWAN 

- OBT 

- SSR 

- LAS CO 

- Large instrument table load commands and trouble shooting 

Test Day 4 (June 1) 

- CELIAS 

CEPAC 

Test Day 5 (June 2) 

Polarity Check 

- CDS 

Test Day 6 (June 6) (14 hours) 

- CDS 

Test Day 7 (June 7) (15 hours) 

- MDI 

- GOLF 

Test Day 8 (June 8) 

- MDI 

- SUMER 

Test Day 9-10 (June 9-10) 

36 hour continual L&EOP Sequence 
================== RFC 822 Headers ================== 

Return- Path: /l=D/G=KEITH/S=WALYUS/0=GSFCMAIL/PRMD=GSFC/ADMD=TELEMAIL/C=US/@x400 
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Date: Wed, 31 May 1995 17:43:00 -0400 

X4 00 -Originator: /I=D/G=KEITH/S=WALYUS/0=GSFCMAIL/PRMD=GSFC/ADMD=TELEMAIL/C=US/@ 
X400-Recipients : non-disclosure:; 

X400 -MTS -Identifier: [/PRMD=gsfc/ADMD=telemail/C=us/;AJJF- 1827-3716/15] 

X4 00 -Content -Type: P2-1984 (2) 

From: /I=D/G=KEITH/S=WALYUS/0=GSFCMAIL/PRMD=GSFC/ADMD=TELEMAIL/C=US/@x400 . gsf C . n 
Message -ID: <AJJF- 1827- 3716/15*@MHS> 

To : /DD -UN=SOHOSIT/O=GSFCMAIL/PRMD=GSFC/ADMD=TELEMAIL/C=US/@x400 . gsf c . nasa . gov, 
cst@sdac . gsf c . nasa . gov , Robert_0 ' Brien@ccmail . gsf c . nasa . gov, 

Ralph. Vi ehman@c email . gsf c . nasa . gov, Michael .Richter@gsfc . nasa . gov, 
/DD.UN=DPERKINS/0=GSFCMAIL/PRMD=GSFC/ADMD=TELEMAIL/C=US/@x400 . gsf c . nasa. gov, 
/DD.UN=VOXENHAM/O=GSFCMAIL/PRMD=GSFC/ADMD=TELEMAIL/C=US/@x400 . gsf c . nasa . gov' 
/DD . UN= JBRUNER/0=GSFCMAIL/PRMD=GSFC/ADMD=TELEMAIL/C=US /@x400 . gsf c . nasa . gov 
Subject: GSCT-2 Summary for Test Day 2 (May 31) 



From: MX%"cst@sdac . gsfc.nasa.gov" 2-JUN-1995 02:21:50.17 

To : MX% "vdomingo@soho . estec . esa . nl " , MX% " lsanchez@soho . estec . esa . nl " , MX% "bf le 

CC: 

Subj : FWD of K. Walyus GSCT#2 Day 3 Summary 

Return- Path: <cst@sdac . gsf c . nasa . gov> 

Received: from SDAC (sdac.gsfc.nasa.gov) by UMDSP.UMD.EDU (MX V4.0-1 VAX) with 
SMTP; Fri, 02 Jun 1995 02:21:47 EDT 
Date: Fri, 2 Jun 1995 02:13:26 -0400 
Message- ID : <95060202132685@sdac . gsf c . nasa . gov> 

From: cst@sdac.gsfc.nasa.gov (CHRIS ST. CYR/ATSC/S0H0/ 682/GSFC 
(301-286-2941) ) 

To: vdomingo@soho.estec.esa.nl, lsanchez@soho.estec.esa.nl, 
bf leck@soho . estec . esa . nl , pmartens@lion . nascom. nasa . gov, 
kim@ecsman . nascom . nasa . gov, elarduinat@ess -mail . atsc . allied . com, 
rock@quake . stanford.edu, scott@quake . stanford.edu, 
wal ter . schmidt@f mi . f i , curdt@l inaxl . dne t . gwdg . de , 
howard@maple . nrl . navy.mil , scott@argus . nrl .navy.mil , 
wang@cedar . nrl . navy.mil , eit@xanado . nascom.nasa.gov, 
mueller-mellin@kernphysik.uni-kiel .d400 .de, lumme@sara.utu. fi, 
galvin@umdsp . umd . edu , wur z@phim . unibe . ch , buergi@mpe - gar ching . mpg . de , 
petrou@sapvxg . saclay . cea . f r , cf rohlich@ezrzl . vmsmail . ethz . ch, 
fgr@ll . iac . es , harrison@solg2 .bnsc .rl.ac.uk, payne@solg2 .bnsc .rl.ac.uk, 
macwan@orpheus . nascom. nasa . gov, lwang@orpheus . nascom. nasa . gov, 
lutter@orpheus . nascom. nasa . gov 
Subject: FWD of K. Walyus GSCT#2 Day 3 Summary 
X- VMS -To: @SUMMARY 

X-MX-Warning: VMS Mail To: line does not include all To: addresses 
GSCT#2 Summary for Test Day 3 (june 1) 

- FOT testing began at 02:10 (local) and completed at 14:30. The 
testing was extended a half hour to accomodate LASCO testing. 

- MMS engineers have reported that the SCOE has been fixed and is 
ready for use. The FOT will test 3 hours of AOCS procedures during 
the afternoon of Day 4. If problems reoccur with the SCOE, the FOT 
will be ready to continue LASCO as a back-up plan. 

- Test Day 4 will be extended four hours to account for the added 
AOCS testing. 

- The tentative schedule through June 10 is listed below. Except for 
three hours of AOCS testing and three hours of LASCO testing, all 
activities have been accounted for in the schedule. Days 11-13 
(June 12-14) have not changed from the original baseline schedule. 

All days have the nominal 11 hour schedule unless otherwise noted. 

Tentative Schedule of Test Days 4-10 (June 2 -June 10) 

Test Day 4 (June 2) (16 hours) 

- CELIAS 

- SSR test 

- LASCO test of transition to submode 2 

- CEPAC 

- AOCS (3 hours) 

Test Day 5 (June 3) 

- Polarity check 

- LIT trouble shooting 



CDS 


Test Day 6 (June 6) (16 hours) 

- CDS 

- Warm start up 

Test Day 7 (June 7) (15 hours) 

- MDI 

- GOLF 

Test Day 8 (June 8) 

- MDI 

- SUMER 

Test Day 9-10 (June 9-10) 

- 36 hour continuous LEOP sequence 



From: MX% "cst@sdac . gsf c . nasa . gov" 3-JUN-1995 02:55:20.32 

To : MX% " vdomingo@soho . es tec . esa . nl " , MX% " lsanchez@soho . es tec . esa . nl " , MX% "bf le 

CC: 

Subj : GSCT#2 summary for test day 4 

Return- Path: <cst@sdac . gsf c . nasa . gov> 

Received: from SDAC (sdac.gsfc.nasa.gov) by UMDSP.UMD.EDU (MX V4.0-1 VAX) with 
SMTP; Sat, 03 Jun 1995 02:55:18 EDT 
Date: Sat, 3 Jun 1995 02:53:26 -0400 
Message- ID : <950603 02532 611@sdac . gsf c . nasa . gov> 

From: cst@sdac.gsfc.nasa.gov (CHRIS ST. CYR/ATSC/SOHO/682 /GSFC 
(301-286-2941)) 

To: vdomingo@soho.estec.esa.nl, lsanchez@soho.estec.esa.nl, 
bf leck@soho . estec . esa . nl , pmartens@lion . nascom. nasa . gov, 
kim@ecsman.nascom.nasa.gov, elarduinat@ess-mail.atsc.allied.com, 
rock@quake . Stanford . edu , scott@quake . Stanford . edu , 
waiter . schmidt@fmi . f i , curdt@linaxl . dnet . gwdg . de , 
howard@maple . nrl . navy.mil , scott@argus . nrl . navy.mil , 
wang@cedar . nrl . navy.mil , eit@xanado . nascom. nasa . gov, 
mueller-mellin@kernphysik.uni-kiel.d400.de, lumme@sara.utu. f i, 
galvin@umdsp . umd . edu , wurz@phim . unibe . ch , buergi@mpe - garching . mpg . de , 
petrou@sapvxg . saclay . cea . f r , cf rohlich@ezrzl . vmsmail . ethz . ch, 
fgr@ll . iac . es, harrison@solg2 .bnsc.rl.ac.uk, payne@solg2.bnsc.rl.ac.uk, 
macwan@orpheus . nascom. nasa . gov, lwang@orpheus . nascom. nasa . gov, 
lutter@orpheus.nascom.nasa.gov 
Subject: GSCT#2 summary for test day 4 
X- VMS -To: ©SUMMARY 

X-MX- Warning: VMS Mail To: line does not include all To: addresses 
FROM: K. Walyus 

GSCT#2 Summary for Test Day 4 (June 2) 

- FOT testing began at 02:22 (local) and completed at 14:30. 

- On test day 4, the FOT completed testing of CELIAS and had 
started testing the CEPAC instrument when the command link was lost. 

No additional testing was possible for that day, while MMS personnel 

worked to re-establish the link. The link was re-established at 17:50 (local) 
and test commands were sent from the POCC to verify the link in 
preparation for testing tomorrow. Additionally, with the SCOE once 
again working, the FOT were able to accomplish 1 hour of PCPG 
(Payload Calibration Profile Generator) testing. 

- The tentative schedule through June 10 is listed below. Except for 
three hours of AOCS testing, three hours of LASCO testing, and six 
hours of CDS testing, all activities have been accounted for in the 
schedule. ESA will work with MMS to arrange additional test time 
during next week to account for the missing twelve hours. Days 11-13 
(June 12-14) have not changed from the original baseline schedule. 

Tentative Schedule of Test Days 5-10 (June 3 -June 10) 

Test Day 5 (June 3) (12 hours) 

- Polarity check 

- Roll steering 

- LIT trouble shooting 

- CEPAC 

- PCPG test 

- SSU 



From: MX% "cst@sdac . gsf c . nasa . gov" 5-JUN-1995 06:32:52.65 

To : MX% "vdomingo@soho . estec . esa . nl " , MX% " lsanchez@soho . estec . esa . nl " , MX% "bf le 

CC: 

Subj : K. Walyus Summary of Day 5 GSCT#2 activities 

Return- Path: <cst@sdac . gsf c . nasa . gov> 

Received: from SDAC (sdac.gsfc.nasa.gov) by UMDSP.UMD.EDU (MX V4.0-1 VAX) with 
SMTP; Mon, 05 Jun 1995 06:32:50 EDT 
Date: Mon, 5 Jun 1995 06:30:53 -0400 
Message- ID : <950605063 053 03@sdac . gsf c . nasa . gov> 

From: cst@sdac.gsfc.nasa.gov (CHRIS ST. CYR/ATSC/SOHO/682/GSFC 
(301-286-2941) ) 

To: vdomingo@soho.estec.esa.nl, lsanchez@soho.estec.esa.nl, 
bf leck@soho . estec . esa . nl , pmartens@lion. nascom.nasa . gov, 
kim@ecsman . nascom.nasa . gov, elarduinat@ess -mail . atsc . allied . com, 
rock@quake . Stanford . edu , scott@quake . Stanford . edu , 
waiter . schmidt@f mi . f i , curdt@l inaxl . dne t . gwdg . de , 
howard@maple . nrl . navy . mil , scot t@argus . nrl . navy.mil , 
wang@cedar .nrl .navy.mil , eit@xanado.nascom.nasa.gov, 
mueller-mellin@kernphysik . uni - kiel .d400.de, lumme@sara . utu . f i , 
galvin@umdsp . umd . edu , wur z@phim . unibe . ch , buergi@mpe - gar ching . mpg . de , 
pe t r ou@s apvxg . saclay . cea . f r , cf rohlich@ezrzl . vmsmail . ethz . ch, 
fgr@ll . iac.es, harrison@solg2 .bnsc.rl.ac.uk, payne@solg2.bnsc.rl.ac.uk, 
macwan@orpheus . nascom.nasa . gov, lwang@orpheus .nascom. nasa . gov, 
lutter@orpheus . nascom.nasa . gov 
Subject: K. Walyus Summary of Day 5 GSCT#2 activities 
X - VMS - To : @SUMMARY 

X-MX-Warning: VMS Mail To: line does not include all To: addresses 
GSCT#2 Summary for Test Day 6 (June 3) 

- FOT testing began at 02:35 (local) and completed at 14:00. 

- On day 5 the FOT completed testing of the CEPAC instrument. On the 
SVM, the FOT completed the polarity check although the FPSS portion 
of the test was dropped due to hardware limitations at MMS . 

Testing of the roll steering law update and the PCPG sequence test will 
be postponed to a later test date due to the spacecraft not being in the 
proper configuration to support this test. The PCPG sequence test and 
the roll steering law update will be conducted in parallel with 
instrument observation time during next week. 

- One hour of test time was also devoted to analyzing the anomaly 
associated with the large instrument table loads. Two LASC0 
background queue loads were sent five times with respective delays of 
5, 4, 3, 2, and 1 second. All commands went through without error. 

Four LASCO command loads were then sent with delays of one second, 
and then again with zero seconds. The LASCO commands at one second 
worked, although the commands with a zero second delay failed. The 
CEPAC delayed command load that failed yesterday (with a delay of 
one second) was resent, and this time the command worked. Similarly 
an MDI background queue command was sent with a delay of one 

second and it also worked. If time permits on Tuesday, the FOT will 
attempt to recreate the CELIAS error. All commands on Tuesday 
(except for the CELIAS test) will use the five second delay. 

- On test day 6 the FOT will begin testing of CDS and perform the 
warm start-up test. Current plans are to test for 16 hours on Tuesday 
with 14 hours being reserved for CDS and two hours being reserved for 
the warm start-up. ESA/MMS must confirm that 16 hours are available 



for testing on Tuesday. If only 15 hours of testing are available, then 
CDS will only be able to test for 13 hours on Tuesday, and one more hour 
of CDS testing will have to be accounted for at a later date. 

The tentative schedule through June 10 is listed below. Except for 
three hours of AOCS testing, three hours of LASCO testing, and six 
hours of CDS testing, all activities have been accounted for in the 
schedule. ESA will work with MMS to arrange additional test time 
during next week to account for the missing twelve hours. Days 11-13 
(June 12-14) have not changed from the original baseline schedule. 

Tentative Schedule of Test Days 6-10 (June 6-10) 

Test Day 6 (June 6) (16 hours) 

- CDS 

- PCPG sequence (if time available) 

- Roll steering law update (if time available) 

- Warm start-up 

- Recreation of CELIAS NRT error (if time allows) 

Test Day 7 (June 7) (15 hours) 

- MDI 

- GOLF 

Test Day 8 (June 8) (11 hours) 

- MDI 

- SUMER 

Test Day 9-10 (June 9-10) 

- 36 hour continual L&EOP Sequence 



From: MX%"cst@sdac . gsf c . nasa . gov" 7-JUN-1995 07:49:43.22 

To : MX% "soc@soc . nascom. nasa . gov" , MX% " vdomingo@soho . estec . esa . nl " , MX% "lsanche 

Subj : GSCT#2 Day 6 summary 

Return- Path : <cst@sdac . gsf c . nasa . gov> 

Received: from SDAC (sdac.gsfc.nasa.gov) by UMDSP.UMD.EDU (MX V4.0-1 VAX) with 
SMTP; Wed, 07 Jun 1995 07:49:41 EDT 
Date: Wed, 7 Jun 1995 07:37:16 -0400 - 

Message-ID: <95060707371612@sdac . gsf c . nasa . gov> 

From: cst@sdac.gsfc.nasa.gov (CHRIS ST. CYR/ATSC/SOHO/682/GSFC 
(301-286-2941)) 

To: soc@soc.nascom.nasa.gov, vdomingo@soho.estec.esa.nl, 
lsanchez@soho . estec . esa . nl , bf leck@soho . estec . esa . nl , 
pmartens@lion . nascom . nasa . gov, kim@ecsman . nascom. nasa . gov, 
elarduinat@ess -mail . atsc . allied . com, rock@quake . Stanford . edu , 
scott@quake . stanford.edu, walter.schmidt@fmi.fi, 
curdt@l inaxl . dnet . gwdg . de , howard@maple . nrl . navy . mil , 
scot t@argus . nrl . navy . mil , wang@cedar . nrl . navy . mil , 

eit@xanado.nascom.nasa.gov, mueller-mellin@kernphysik.uni-kiel.d400.de, 
lumme@sara.utu.fi, galvin@umdsp.umd.edu, wurz@phim.unibe. ch, 
buergi@mpe - garching . mpg . de , pe t rou@sapvxg . saclay . cea . f r , 
cf rohlich@ezrzl . vmsmail . ethz . ch, fgr@ll . iac . es , 
harrison@solg2 .bnsc .rl.ac.uk, payne@solg2 .bnsc .rl.ac.uk, 
macwan@orpheus . nascom. nasa . gov, lwang@orpheus . nascom. nasa . gov, 
lutter@orpheus.nascom.nasa.gov 
Subject: GSCT#2 Day 6 summary 
X - VMS - To : ©SUMMARY 

X-MX- Warning: VMS Mail To: line does not include all To: addresses 
GSCT#2 Summary for Test Day 6 (June 06) -- CSt version 

- FOT testing began at 02:00 (local) and completed at 14:20. 

- On day 6, the FOT completed the first portion of CDS testing 
and completed the PCPG sequence. At the end of the day the FOT 
also re-created the CELIAS NRT problem. 

- Preliminary results from the continuing analysis of the NRT commanding 
problems indicate that NASA's PDF interface in Toulouse (between the 
telephone line and the CCS front end) may be the site of the problem. 

Further analysis will be necessary to confirm this, but the remainder 

of GSCT#2 commanding will be performed with a 3 second delay between commands 
leaving the POCC. This delay should provide sufficient margin to keep 
the CCS from crashing. If problems occur at this delay rate, the delay 
will be increased to 5 seconds. 

- In order to complete the scheduled CDS time, the FOT may have to truncate 
the LEOP testing by one hour. 

- The tentative schedule through June 14 is listed below. 

Test Day 7 (June 7) (12 hours) 

- MDI (9 hours) 

- Warm start-up (3 hours) 

- Individual thruster firing (if time available) 

- SSR test (if time available) 

- Roll steering law update (if time available) 

- SSU/SEU (if time available) 



Test Day 8 (June 8) (24 hours) 

- MDI (8 hours) 

- SUMER (5 hours) 

- GOLF (3 hours) 

- LASCO (3 hours) 

- CDS ( 5 hours ) 

Test Day 9-10 (June 9-10) (24 hours) 

- CDS (1 hour) 

- 35 hour continual LEOP sequence (until 14:00 Saturday) 
Test Day 11 (June 12) 

- System test (multi -experiment commanding) 

Test Day 12 (June 13) 

- System test (multi -experiment NRT) 

Test Day 13 (June 14) 

- AOCS-ESR test 



From: MX% "cst@sdac . gsf c . nasa . gov" 9-JUN-1995 01:52:54.83 

To : MX% "soc@soc . nascom. nasa . gov" , MX% "vdomingo@soho . estec . esa . nl " , MX% " lsanche 

CC: 

Subj : GSCT#2 Summary for test day 8 

Return- Path : <cst@sdac . gsf c . nasa . gov> 

Received: from SDAC (sdac.gsfc.nasa.gov) by UMDSP.UMD.EDU (MX V4.0-1 VAX) with 
SMTP; Fri, 09 Jun 1995 01:52:52 EDT 
Date: Fri, 9 Jun 1995 01:48:55 -0400 
Message- ID: <950609 0148555 0@sdac . gsf c . nasa . gov> 

From: cst@sdac.gsfc.nasa.gov (CHRIS ST. CYR/ATSC/SOHO/682/GSFC 
(301-286-2941) ) 

To: soc@soc.nascom.nasa.gov, vdomingo@soho.estec.esa.nl, 
lsanchez@soho . estec . esa . nl , bf leck@soho . estec . esa . nl , 
pmartens@lion . nascom. nasa . gov, kim@ecsman . nascom. nasa . gov, 
elarduinat@ess-mail . atsc . allied. com, rock@quake . Stanford . edu, 
scott@quake . stanford.edu, waiter . schmidt@fmi . f i, 
curdt@linaxl.dnet.gwdg.de, howard@maple.nrl.navy.mil, 
scott@argus . nrl . navy.mil , wang@cedar.nrl .navy.mil , 

eit@xanado . nascom . nasa . gov, mueller-mellin@kernphysik . uni - kiel .d400.de, 
lumme@sara.utu.fi, galvin@umdsp.umd.edu, wurz@phim.unibe . ch, 
buergi@mpe - garching . mpg . de , pe t rou@sapvxg . saclay . cea . f r , 
cf rohlich@ezrzl . vmsmail . ethz . ch, fgr@ll . iac.es , 
harrison@solg2 . bnsc .rl.ac.uk, payne@solg2 .bnsc . rl .ac.uk, 
macwan@orpheus . nascom. nasa . gov, lwang@orpheus .nascom. nasa . gov, 
lutter@orpheus . nascom. nasa . gov 
Subject: GSCT#2 Summary for test day 8 
X - VMS - To : @SUMMARY 

X-MX-Warning: VMS Mail To: line does not include all To: addresses 
GSCT#2 Summary for Test Day 8 (June 08) 

- FOT testing began at 03:00 (local) and continues. 

- The FOT completed the MDI, GOLF, and SUMER testing. 

- The tentative schedule through June 14 is listed below. 

During continual operations, shift change briefings will occur 
at 01:00 and 13:00 each day. 

- In order to complete the CDS testing, the FOT may not begin the 
LEOP testing until 04:30 on test day 9. This delay would leave only 
33.5 hours to test the LEOP sequence (originally baselined as 36 hours). 

If the LEOP activities are not complete by 14:00 Saturday, the 
remaining LEOP activities will be deleted. 

Tentative schedule for test days 8-13 (June 8-14) 

Test Day 8 (08 June) 

- MDI (completed) 

- GOLF (completed) 

- SUMER (completed) 

- LASCO and CDS turn-on (1.5 hours) 

- LASCO (3 hours) 

- CDS (3.5 hours ) 

- SSR test (if time available) 

Test Day 9-10 (09-10 June) 

- CDS (2.5 hours ) 

- 33.5 hours continual LEOP sequence (or until 14:00 Saturday) 



- Individual thruster firing (if time available) 

- Roll steering law update (if time available) 

- SSU/SEU (if time available) 

Test Day 11 (12 June) 

- System test -- multi -experiments 

Test Day 12 (13 June) 

- System test -- simultaneous NRT — 

Test Day 13 (14 June) 

- AOCS - ESR test 



From: MX%"cst@sdac . gsf c . nasa . gov" 10-JUN-1995 02:55:42.20 

To : MX% "soc@soc . nascom. nasa . gov" , MX% " vdomingo@soho . estec . esa . nl " , MX% " lsanche 

CC: 

Subj : GSCT#2 Summary for test day 9 

Return- Path : <cst@sdac . gsf c . nasa . gov> 

Received: from SDAC (sdac.gsfc.nasa.gov) by UMDSP.UMD.EDU (MX V4.0-1 VAX) with 
SMTP; Sat, 10 Jun 1995 02:55:40 EDT 
Date: Sat, 10 Jun 1995 02:54:28 -0400 
Message- ID : <95061002542843@sdac . gsf c . nasa . gov> 

From: cst@sdac.gsfc.nasa.gov (CHRIS ST . CYR/ATSC / SOHO / 6 82 /GS FC 
(301-286-2941)) 

To: soc@soc.nascom.nasa.gov, vdomingo@soho.estec.esa.nl, 
lsanchez@soho . estec . esa . nl , bf leck@soho . estec . esa . nl , 
pmartens@lion . nascom. nasa . gov, kim@ecsman . nascom. nasa . gov, 
elarduinat@ess-mail.atsc.allied.com, rock@quake.stanford.edu, 
scott@quake . Stanford . edu, waiter. schmidt@fmi . f i , 
curdt@linaxl . dnet . gwdg . de , howard@maple . nrl . navy.mil , 
scott@argus.nrl.navy.mil , wang@cedar.nrl.navy.mil, 

eit@xanado . nascom. nasa . gov, mueller-mellin@kernphysik. uni - kiel .d400.de, 
lumme@sara.utu.fi, galvin@umdsp.umd.edu, wurz@phim.unibe . ch, 
buergi@mpe - garching . mpg . de , petrou@sapvxg . saclay . cea . f r , 
cf rohlich@ezrzl . vmsmail . ethz . ch, fgr@ll . iac . es, 
harrison@solg2 . bns c . rl . ac . uk , payne@solg2 . bnsc .rl.ac.uk, 
macwan@orpheus . nascom. nasa . gov, lwang@orpheus . nascom. nasa . gov, 
lutter@orpheus.nascom.nasa.gov 
Subject: GSCT#2 Summary for test day 9 
X- VMS -To: ©SUMMARY 

X-MX-Warning: VMS Mail To: line does not include all To: addresses 
GSCT#2 Summary for Test Day 9 (June 09) as of 18:00 loca 

- Since the beginning of test day 8 at 02:00 (local), the test 
team has been operating continuously. Testing activities are 
scheduled until 14:00 on Saturday. 

- On day 9 the FOT completed testing of LASCO and CDS, and they 

are now progressing through the LEOP sequence, which began at 05:00. 

- On Saturday (day 10) the shift-change briefing will occur at 01:00, 
a status update will be presented at 09:00, and the day's debriefing 
will be one-half hour after completion of the day's activities 
(estimated time of debrief 14:30). 

- Due to the tight schedule for completing the LEOP sequence, several 
activities will be postponed until next week (individual thruster 
firing, roll steering law update, and SSU/SEU tests) . Due to technical 
problems with testing the SSR, this will also be postponed. 

ESA/MMS will investigate the possibility of adding time to next week's 
schedule to allow the FOT to complete these tests. 

- The tentative schedule through June 14 is listed below. 

Test Day 9-10 (09-10 June) 

- CDS (completed) 

- 33.5 hours continual LEOP sequence (or until 14:00 Saturday) 

Test Day 11 (12 June) 

- System test -- multi -experiments 



Test Day 12 (13 June) 

- System test -- simultaneous NRT 

Test Day 13 (14 June) 

- AOCS - ESR test 

Tests Remaining to be scheduled: 

- Individual thruster firing (if time available) 

- Roll steering law update (if time available) 

- SSU/SEU (if time available) 



From: MX%"cst@sdac . gsf c . nasa . gov" 12-JUN-1995 13:44:42.31 

To : MX% "soc@soc . nascom. nasa . gov" , MX% " vdomingo@soho . estec . esa . nl " , MX% " lsanche 

CC: 

Subj : GSCT#2 Summary for test day 10 

Return- Path: <cst@sdac . gsf c . nasa . gov> 

Received: from SDAC (sdac.gsfc.nasa.gov) by UMDSP.UMD.EDU (MX V4.0-1 VAX) with 
SMTP; Mon, 12 Jun 1995 13:44:39 EDT 
Date: Mon, 12 Jun 1995 03:10:05 -0400 
Message- ID: <9 50612 03 10055 5@sdac . gsf c . nasa . gov> 

From: cst@sdac.gsfc.nasa.gov (CHRIS ST. CYR/ATSC/SOHO/682/GSFC 
(301-286-2941)) 

To: soc@soc.nascom.nasa.gov, vdomingo@soho.estec.esa.nl, 
lsanchez@soho . estec . esa . nl , bf leck@soho . estec . esa . nl , 
pmartens@lion . nascom . nasa . gov, kim@ecsman . nascom. nasa . gov, 
elarduinat@ess-mail . atsc . allied . com, rock@quake . Stanford . edu, 
scott@quake . Stanford. edu, waiter . schmidt@fmi . f i , 
curdt@linaxl . dnet . gwdg . de , howard@maple . nrl . navy.mil , 
scot t@argus . nrl . navy . mil , wang@cedar . nrl . navy . mil , 

eit@xanado . nascom. nasa . gov, mueller-mellin@kernphysik . uni - kiel . d400 . de , 
lumme@sara.utu.fi, galvin@umdsp.umd.edu, wurz@phim.unibe . ch, 
buergi@mpe - garching . mpg . de , pet rou@sapvxg . saclay . cea . f r , 
cf rohlich@ezrzl . vmsmail . ethz . ch, fgr@ll . iac.es , 
harrison@solg2 . bnsc . rl . ac . uk, payne@solg2 .bnsc .rl.ac.uk, 
macwan@orpheus . nascom. nasa . gov, lwang@orpheus . nascom. nasa . gov, 
lutter@orpheus.nascom.nasa.gov 
Subject: GSCT#2 Summary for test day 10 
X- VMS -To: ©SUMMARY 

X-MX-Warning : VMS Mail To: line does not include all To: addresses 
GSCT#2 Summary for Test Day 10 (10 June) 

- The test team completed the 60 continuous hours of testing at 14:30 (local) 
today. 

- The FOT completed the LEOP sequence; however, the results of some parts 
were not satisfactory and will need to be regression tested. Total 
non-budgeted test time is now estimated at nine hours (including the 
regression testing) . ESA is currently investigating the possibility 

of adding another night shift operation between Tuesday and Wednesday, 
which would give 36 hours of continuous testing beginning Tuesday at 02:00 
and concluding at 14:00 Wednesday. 

- The FOT will give a preliminary debrief after the conclusion 
of the test on Wednesday. 

- The tentative schedule is listed below: 

Test Day 11 (12 June) 

- System test; multi -experiment tasks; 1.6 hour pass 
Test Day 12 (13 June) 

- System test; multi -experiment tasks; 

Test Day 13 (14 June) 

- A0CS-ESR test 


8 hour pass 



From: MX% "cst@sdac . gsf c . nasa . gov" 13-JUN-1995 03:19:30.39 

To: MX%"soc@soc .nascom.nasa.gov" , MX% "vdomingo@soho. estec . esa.nl " ,MX%"lsanche 

CC: 

Subj : Summary for test day 11 of GSCT#2 

Return- Path: <cst@sdac . gsf c . nasa . gov> 

Received: from SDAC (sdac.gsfc.nasa.gov) by UMDSP.UMD.EDU (MX V4.0-1 VAX) with 
SMTP; Tue, 13 Jun 1995 03:19:27 EDT 
Date: Tue, 13 Jun 1995 03:10:58 -0400 
Message- ID: <95061303105848@sdac . gsf c .nasa . gov> 

From: cst@sdac.gsfc.nasa.gov (CHRIS ST. CYR/ATSC/SOHO/682 /GSFC 
(301-286-2941)) 

To: soc@soc.nascom.nasa.gov, vdomingo@soho.estec.esa.nl, 
lsanchez@soho . estec . esa . nl , bf leck@soho . estec . esa . nl , 
pmartens@lion . nascom . nasa . gov, kim@ecsman . nascom. nasa . gov, 
elarduinat@ess-mail . at sc . allied . com, rock@quake . Stanford . edu, 
scott@quake . Stanford. edu, waiter. schmidt@fmi . f i, 
curdt@linaxl.dnet.gwdg.de, howard@maple.nrl.navy.mil, 
scot t@argus . nrl . navy . mil , wang@cedar . nrl . navy . mil , 

ei t@xanado . nas com . nasa . gov , muel 1 er - mel 1 in@kernphys ik.uni-kiel.d400.de, 
lumme@sara.utu.fi, galvin@umdsp.umd.edu, wurz@phim.unibe . ch, 
buergi@mpe - garching . mpg . de , pe t rou@sapvxg . saclay . cea . f r , 
cf rohlich@ezrzl . vmsmail . ethz . ch, f gr@ll . iac . es , 
harrison@solg2 .bnsc .rl.ac.uk, payne@solg2 .bnsc .rl.ac.uk, 
macwan@orpheus . nascom. nasa . gov, lwang@orpheus .nascom. nasa . gov, 
lutter@orpheus . nascom. nasa . gov 
Subject: Summary for test day 11 of GSCT#2 
X - VMS - To : ©SUMMARY 

X-MX-Warning: VMS Mail To: line does not include all To: addresses 
GSCT#2 Summary for Test Day 11 (12 June) 

- FOT testing began at 04:55 (local and completed at 15:20. 

- FOT testing on day 11 included a simulation of the nominal 1.6 hour pass 
and a test of the thruster firing function. The PI teams also conducted 
combined NRT testing. 

- The duration for test day 12 has been lengthened to 13 hours and is 
scheduled to compete at 15:00. The FOT has requested that the day 

be lengthened to 16:00 in order to complete all scheduled activities. 

- On Wednesday the FOT will give a preliminary debrief after the 
conclusion of the test. 

Tentative Test Schedule 

Test Day 12 (13 June) 

- System test with experiments, simultaneous NRT commanding 

- Roll steering law update 

- Warm start-up procedures 

- Remaining SSR tests 

- I IDE test 

- ESR warning flag receipt definition 

Test Day 13 (14 June) 

- AOCS-ESR test 



From: MX% "vdomingo@esa . nascom. nasa . gov" l-SEP-1995 08:47:58.58 

To : MX% "dhovestadt@solar . Stanford . edu " , MX% "galvin@umdsp . umd . edu" 

Subj : GSCT#3 additional operation time 

Return-Path: <vdomingo@esa. nascom. nasa. gov> 

Received: from gsfc.nasa.gov by UMDSP.UMD.EDU (MX V4.0-1 VAX) with SMTP; Fri, 

01 Sep 1995 08:47:56 EDT 

Received: from esa.nascom.nasa.gov by gsfc.nasa.gov (5 . 65/Ultrix3 .0-C) id 
AA02947; Fri, 1 Sep 95 08:48:28 -0400 

Received: from seal.nascom.nasa.gov by esa (5 .x/SMI-SVR4) id AA17679; Fri, 1 Sep 
1995 08:49:22 -0400 

Received: by seal.nascom.nasa.gov (SMI-8 . 6/SMI-SVR4) id IAA13896; Fri, 1 Sep 
1995 08:49:21 -0400 
Date: Fri, 1 Sep 1995 08:49:21 -0400 
From: vdomingo@esa.nascom.nasa.gov (Vicente Domingo) 

Message- ID : <199509011249. IAA13896@seal . nascom. nasa . gov> 

To: dhovestadt@solar.stanford.edu, galvin@umdsp.umd.edu 
Subject: GSCT#3 additional operation time 
X- Sun -Charset: US -ASCII 

Dear Dieter, Toni, 

This mal sohuld have been addressed to you as well . 

Would you please let me known the e-mail address of Peter Wurz? 

Best wishes, Vicente 


Begin Included Message 

From vdomingo Thu Aug 31 17:58:18 1995 

To: harrison@solg2.bnsc.rl.ac.uk, @estgtw. estec . esa.nl :nsp: : linmpi : :wilhelm, @es 
Subject: GSCT#3 additional operation time 

To PI and EOF team representatives of CDS, SUMER, MDI, LASCO/EIT, UVCS, 

CEPAC: 

Copy: C. Berner, K. Walyus, C. Cazeau, H. Schweitzer, A. Poland 


In the GSCT#3 preliminary script there are allocatedthe following 
dedicated test periods : 


MDI 

LASCO/EIT 

CDS 

UVCS 


4 hours NRT 
4 hr NRT 
1 hr MCU test 

6.5 hr TSTOL & 6 hr NRT (12.5 hr total) 


After your replies and discussion at the meetings at KSC (PI debriefing 
and SFT review) , my understanding of additional requirements for 
operation during the GSCT#3 are the following: 

CEPAC 4 hours TSTOL procedures (at least) 

SUMER 2 hr dedicated NRT - focusing mechanism lock 

CDS 2 hr dedicated NRT - tentative - to be confirmed Sept 5th. 

CELIAS 4 hr TSTOL procedures 



This amounts to additional 12 hours. After discussing with the FOT 
people we realize that if we use one of 8 -hour nominal pass (day 8) 
are still left with 4 hours that cannot be accomodated within the 9 
days foreseen for GSCT#3 . 

It appears that either an additional day will have to be added to 
GSCT#3 or that some days will have to grow longer. 

Please verify that your requirements are correct and reply to me as 
soon as possible, by early September 5th (US EST) at the latest. 


Vicente Domingo 


End Included Message 



From: UMDSP: : GALVIN "Toni Galvin (Univ. Md) " 13 -SEP- 1995 19:45:41.55 

To : @CAZEAU 

CC: @SOWG, GALVIN 

Subj : celias set up for esr test 

Dear Carline, 

The following is the proposed setup for the CELIAS experiment for the 
ESR configuration. It is what we attempted to do during GSCT#2, but there 
were some errors in the command database, which should now be corrected. 

Best regards, Toni Galvin 


The CELIAS experiment should be placed in the following configuration for the 
ESR test. (It is assumed here that Matra is handling the experiment set up 
to save time.) 

(1) Perform Elisa procedure CLS_ON 
CELIAS DPU on 

ESR response commanded to "power off" (command may go into 

affect either within a few minutes, or 21 
hours later) 


(2) Configure ESR response to "standby" 

Send FBCESRSB 

Verify fsdesrd is "Standby " 

(3) Configure sensors for test 

Send FBCM0D1I CTOF standby mode, immediate 

Send FBMM0D1I MTOF standby mode, immediate 

Send FBSMODOI STOF power off mode, immediate 

The above can also be done using the following Elisa procedures: 

CLS_CTOF_ON 

CLS_MTOF__ON 

CLS_STOF_OFF 

Verify fsdmods is "Power Off" 
fsdmodc is "Standby" 

fsdmodm is "Standby" 

Send FBCM0D3I CTOF verify mode, immediate 

The above can also be done using the following Elisa procedure: 

CLS_CTCAL_ON 

Verify fsdmodc is "Verify" 


AFTER ESR FLAG IS RECEIVED: 



(4) 


Experimenter will check that the following occurred: 

Verify fsdmodc is "Standby" 
fsdmodm is "Standby" 
fsdmods is "Power Off" 

AFTER THE TEST COMPLETION: 

(5) If possible, before the power off of the experiment perform the 
following xTOF power off procedures: 

CLS_CTOF_OFF 
CLS_MTOF_OFF 
CLS STOF OFF 



From: UMDSP: : GALVIN "Toni Galvin (Univ. Md) " 17 -OCT- 1995 15:56:07.26 

To : @SOWG , MPE : : BEK , @HOVESTADT 

CC : GALVIN 

Subj : response to inquiry from Berndt Klecker and Fritz Gliem 

Dear Kay, Please make a hard copy for Fritz, as I am too lazy to go to 
the fax machine ! 

With regard to my travel schedule (in the event of an GSCT#4 , which is 
currently being discussed) : I will be at a Ulysses workshop and SWT 

the week of Oct 22-29. This is the same week as the SOHO AFT and the 
ACE meeting at the Cape. If the project decides on an GSCT#4 on the 
same week, I suspect we will have personnel problems. At this time 
no date has been fixed for the proposed (i.e., tentative) GSCT#4 . 

Again, with regard to another GSCT#4 : 

(1) Although I have a promise from Carline Cazeau (FOT) that the 
database for a Nov launch will have the fixes to our database 
that became apparent after GSCT#3, I will have to check to see 
if it would be ready by an earlier date for GSCT#4. This 
affects the DPU Modify memory commands and associated procedures, 
although we would have a binary command option if necessary. 

(2) Depending on the order of HV- Disable plug removal and the GSCT#4, 
please be careful what you decide to test! I am saying this mainly 
for CTOF and STOF, since my impression is that you routinely 
command your HV's during SFT's. I will want an EXPLICIT statement 
from each LEAD COI stating what is OK to do! I have been told 

(by Dieter) that Heiner is removing CTOF plugs early, while he 
is at the Cape. If so, CTOF will be "at risk" longer than the 
other sensors. 

With regard to F. Gliem' s and K. Reiche's fax: 

I discussed some of this with Chris StCyr during the last GSCT#3 . These 
things have a way of changing over time, and also depends on whom you 
talk to. If anything I say does not sound correct, or if you want something 
else, just say so and I will check it out with the EOF people. They are 
pretty good at accommodating us, although right now our name is Mudd because 
of the procedure business. (For the non -Americans, to say one's name is 
Mudd means you are in trouble. Dr. Mudd treated Abe Lincoln's assassin 
for a broken leg - not knowing who he was treating. He was convicted of 
treason for it.) 

Local operations: 

Let me break this up into EOF and EAF: 

In the EOF (building 3), we currently have three PC workstations, 
designated CELIAS, CELIAS2, CELIAS3 , and a functional address for 
CELIAS4 (which we have used for laptop computers - both Macintosh 
(Wurz and myself have Mac's) and PC (Gruenwaldt tried this out 
at GSTC#3 as a possible CTOF GSE) ) . In other words, we can FOR SURE 
at REAL TIME DATA on at least four workstations at the EOF. I 
specifically asked St Cyr about additional workstations, and they 
are not a problem as far as getting a connection. There is at 
least one more ethernet wall socket available in our corner. BUT 
I THINK THAT FIVE PC'S ON TWO TABLES WOULD BE SUPER CROWDED. So 
yes, I think we can get a fifth address if we want it - but do 
we? 



Another item: we can also opt for just ethernet access, but not 

ask to get on the REAL TIME socket. That was useful for the 
Macintosh laptops, which of course do not have the PC-based GSE 
programs . 

In the EOF, we can command from any of the PC's, but only one 
at a time (again, as in Gliem's fax). Commands will either be 
by NRT , or using FOT- commanding (via TSTOL procedures - required 
for CRITICAL commands, or via Predefined Command Sequence files, 
which cannot do critical commands, but can do "not -allowed for 
NRT" commands.) 

Here is where I deviate from Gliem's Fax: 

In addition to the EOF, there is the EAF (in building 26) . We have 
one desk area in the EAF for CELIAS use. We can have as many 
computers there as will fit. There will be ethernet connections 
available. We cannot received REAL TIME data outside of the EOF, 
nor can we do NRT commanding outside of the EOF. BUT, you can 

(1) transport (via FTP or floppy disk) data that was 
recorded on the EOF GSE's and replay the recorded data 
on a PC that could be located at the EAF. 

(2) You can receive EOF ARCHIVE TELEMETRY data (*.REL or 
* . QKL files) that contain data that is about 2 hours 
old. This data is similar to what we get on the 
CD-ROMS, except for a difference in the header. 

I discussed the REL and QKL format with Thomas Hauck 
last year. He informed me that the GSE program cannot 
read it, nor were there plans to change that. I also 
discussed this with Peter Wurz, and he indicated that 
Bern would be handling the Level 0 (i.e., CD-ROM type 
data) , but would not be explicitly responsible for 
the archive telemetry data. However, he did take a 
look at the data files, and I do not know if there 
is an update on that aspect or not. We at UMD have 
started looking at the * . REL data, and find it 
pretty straight foreward (which is not an offer to 
volunteer to do any body's programming!). 

In other words, the situation at the EAF is pretty much 

as before: If we have an alpha Vax, we can look at 

Level 0 type data using the Bern program, but can only 

look at GSE data (recorded, not live) with a PC. No 

live data will be available, but data within 2 hours 

for * . REL and >15 minutes for GSE. (However, I do not 

know if you can both record data on the EOF GSE and 

FTP earlier recorded data to another location simultaneously.) 

Whether is is useful to bring the alpha vax to the EAF 
depends on the state of the analysis programming, so I 
cannot answer that query. I think we should at least have 
laptops for communication/office type functions. 


REMOTE: Any data we can get at the EAF, we can get anywhere. The 

various files (e.g., *.REL) are already being sent to 
UMD and to MPE . The Level 0 data should become 
available electronically about 1 -2 days after 
aquisition. That is process by the CDHF, so it takes 



more time. Later, CDHF puts the same data on CD-ROM and 
sends it out. This is similar to WIND. 

Sending GSE data remotely requires, I believe, that someone 
be manually recording, archiving, and ftp-ing the data out. 
Gliem and Reiche should correct me if this can be 
automated? 

REMOTE COMMANDING: This can be either by delayed command, or by 

FOT TSTOL procedures. Theoretically, we can 'also ask 
the project scientist to send commands for us, but then 
we are responsible for having software that works on his 
workstation. That means translating the GSE s/w from a 
PC-based to whatever the PS workstation uses. I do not 
see this happening on our team. 


Anyway, this is how I understand it. 

Berndt: I will have a copy of that document sent out (I found one 

dated may 1995! - it is not the final version , but the last one 
that has been distributed) . 

Heiner - I will see about decompressing those files. I CANNOT help 
you on whether or not data words in a particular command require 
byte swapping or not. That is between you and Kay, at least until 
I have some documentation from Kay on how the commands work. If you 
do not know if certain commands in a procedure are valid or not, I 
do not particularly recommend having the procedure submitted to the 
FOT - where we will end up using wrong data words forever. You need 
to decide on that, before submission. These procedures are meant to 
increase our level of safety and surety, and should have a certain 
confidence level inherent in their use. 


best regards, Toni 



From: UMDSP::SOHO 19-OCT-1995 17:07:28.44 

To: S)S0WG 

CC: 3H0VESTADT , SOHO 

Subj: upcoming gsct#4 - procs and database 


Dear colleagues, 

I have just spoken to Carline Cazeau of the FOT. As you 
know, there is an upcoming GSCT#4, which may occur sometime 
within the next two weeks. (Possibly the weekend of Oct 
28-29, although new dates are rumored for the 30 Oct.) 

(1) This Sunday, 22 October, the new Project Data Base 
will be implemented at the FOT computer. This will include 
our DPU command corrections that were found after the 
GSCT#3. This will not include the new error found in the 
STOF command list, that was just reported this week. 

(2) OK, the bad news. Our new procedures will not be 
ready in time for a test that starts in October. Carline 
says that if we have 2, repeat 2, new procedures that 
we really need to test out, we should send her those names 
(by new, I mean that we have already sent to her these 
past couple of weeks), and she will give them top priority 
in getting done in time for GSCT#4. 

I suggest that we re- test the corrected f_ts_sw_patch 
procedure. This will do two things (1) check the new 
binary equivalent in the command data base, whose error 
was not discovered until we tried this procedure in 
GSCT#3, and (2) check the corrected data word, whose error 
was not discovered until the DPU reset itself during 
GSCT#3. 

Otherwise, I suggest trying to work within the existin 
g test procedures, maybe choosing two new ones that 
are important. (I suggest that this be chosen from 
among STOF, MTOF and DPU, as the CTOF procedures do not 
have any chance of being ready in time - but that decision 
is up to the Pi/Lead-Cols). 

If we have an option, we should make sure we get some 
NRT command time as well as FOT procedure command time. 
Commands that are "ALLOWED" and "NOT CRITICAL" can be 
tested out NRT. 

Car line says there will not be any time available to 
create new PCS files, for RCR use. 


regards, Toni 



